Allow reading more than the minimum number when filling buffer in XmlBufferReader

[Daniel-Svensson]

Read as much as possible into the buffer without limiting to minimum count
Affects at least XmlDictionaryReader

The current code looked a bit odd with ReadAtLeast while still limiting number of bytes read to the minimum number of bytes to read.

[stephentoub]

Affects at least XmlDictionaryReader

Performance or correctness? If the latter, what test can we add?

[stephentoub]

cc: @eerhardt

[stephentoub]

Prior to the change to use ReadAtLeast, this was also limiting how much was read to needed. Is it possible changing it to read more could create bugs? For example, is it possible this might end up reading more from the stream that a consumer intended, such that it would erroneously consume something from the stream after what is being deserialized?

[Daniel-Svensson]

Good catch, I am thinking about closing this for now and maybe add a comment in a separate PR.

Is there any other reader which have any way around that (such as resetting the stream position) and if so how late (dispose or after each read) would it be ok to reset the position?

[stephentoub]

Resetting position isn't always possible: many (most) streams don't support it.

We should just close this PR for now. Thanks, though.

[eerhardt]

The current code looked a bit odd with ReadAtLeast while still limiting number of bytes read to the minimum number of bytes to read.

Note, this code needs to use ReadAtLeast in order to handle EOF correctly. This doesn't want to throw an exception when encountering EOF - it just wants to return false;. If we had an overload to ReadExactly with throwOnEndOfStream, this would use ReadExactly and pass in throwOnEndOfStream: false. But there isn't an overload because ReadExactly is meant to be the "easy" API for most consumers.