SqlDataReader.GetFieldValue{,Async}() should work for Stream and TextReader

Following #30958, where @Wraith2 added the ability to retrieve an XmlReader via SqlDataReader.GetFieldValue() and its async counterpart, we should do the same for Stream and TextReader. These can already be retrieved via GetStream() and GetTextReader() respectively.

The main motivation behind this would be to allow getting Reader/TextReader asynchronously without introducing new GetReaderAsync() and GetTextReaderAsync() methods. See https://github.com/dotnet/corefx/issues/35012#issuecomment-484440830 and below for previous discussion.

[Wraith2]

@roji i’ve got this working on netcore but because of the different netcore and netfx codebases it’s more difficult to get it working on netfx. Since this would primarily be useful from EF and as far as a know modern EF only works on core or net5 onwards is there a need to implement on netfx immediately? It will eventually be implemented through the merging of the codebases.

[Wraith2]

@bgrainger has pointed out in one of the linked issues elsewhere that there is some slightly unexpected (but deliberate) behaviour when using the current sync stream methods, GetStream, GetTextReader and GetXmlReader all handle database NULL values by detecting it and returning an empty stream. Other methods of accessing the same fields will detect null and throw an appropriate exception.

Should GetFieldValue(Async)<T> for stream types emulate the current behaviour of returning a constructed empty stream or should they throw null as GetString or GetBytes would do?

I think it is up to the developer to ensure that their queries return sensible data and that if null can be present in the return from a query it should be explicitly handled by the consumer and not hidden by the ADO library. I’m in favour of throwing an exception if a stream over null data is requested through GetFieldValue(Async)