Don't count start line toward header size limit

[halter73]

At first I thought this regression was caused the recent PR to make header parsing safe, but it looks like it was actually introduced prior to our 3.0 release by #8076. @anurse

This issue only occurs when start line and the headers are received separately, and the total length of the request headers in bytes is close enough to the limit that counting the start line towards it pushes it over. So pretty rare.

We have a bunch tests where the length of the request headers is close enough to the limit that the start line pushes it over, but before this there were no tests that guaranteed that the headers are received separately. After seeing the existing tests repro once locally, I was able to get it to reliably repro by uncommenting the following:

aspnetcore/src/Servers/Kestrel/shared/test/StreamBackedTestConnection.cs

Lines 81 to 88 in be76a03

	for (var index = 0; index < text.Length; index++)
	{
	var ch = text[index];
	writer.Write(ch);
	await writer.FlushAsync().ConfigureAwait(false);
	// Re-add delay to help find socket input consumption bugs more consistently
	//await Task.Delay(TimeSpan.FromMilliseconds(5));
	}

That's not the type of thing we'd want to keep uncommented all the time though since that would slow down test runs about 10x.

@benaadams

[benaadams]

Would await Task.Yield() work rather than Task.Delay?

[halter73]

Would await Task.Yield() work rather than Task.Delay?

That seems to work pretty well. It still reliably repros the issue, without making the test runs take much longer at all (< 10% difference). Probably want to rewrite ContentLengthReadAsyncSingleBytesAtATime before doing this though.

[Tratcher]

Please tell me you kept at least some of the old pragmas? We need something that verifies the old exception is still the one thrown.

[halter73]

There's still one pragma in this test class because it's checking some internal property. I didn't even touch the other test classes.