Fix the buffering bug that blocks SDK

[adamsitnik]

Fixes #51141

I was able to identify the issue (after figuring out which process out of many should be debugged in the SDK repo):

Write a failing test:

And provide a fix;

Some details: it's possible that _writePos == _bufferSize and in such case the next call to any of the Write methods is supposed to flush the write buffer.

[ghost]

Tagging subscribers to this area: @carlossanlop
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I was able to identify the issue (after figuring out which process out of many should be debugged in the SDK repo):

Write a failing test:

And provide a fix;

Some details: it's possible that _writePos == _bufferSize and in such case the next call to any of the Write methods is supposed to flush the write buffer.

Author:	adamsitnik
Assignees:	-
Labels:	area-System.IO
Milestone:	6.0.0

[danmoseley]

Is it worth putting something other than zeros in here? So it's distinct from the first byte you wrote

[carlossanlop]

Doesn't really matter. What matters is that we are attempting to write an 11th character on the stream when the buffer can only hold 10 characters.

[jozkee]

...and the problem was that the internal buffer is not being reset/flushed when WriteByte is called when this buffer is already full.

[jozkee]

Thanks @adamsitnik!

[jozkee]

So this method should only be called when either _writePos == 0 or _writePos == _bufferSize, right?
Consider adding the assertion, but not in this PR since we want to merge it ASAP.

Suggested change

	FlushWrite();
	Debug.Assert(_writePos == _bufferSize);
	FlushWrite();