Skip, quarantine and un-Quarantine

[dougbu]

• un-quarantine ContentLength_Received_MultipleDataFramesOverSize_Reset, Quarantine Http2StreamTests .ContentLength_Received_MultipleDataFramesOverSize_Reset #33373 fix seems to have worked
• quarantine LoggingConnectionMiddlewareCanBeAddedBeforeAndAfterHttps(), LoggingConnectionMiddlewareCanBeAddedBeforeAndAfterHttps() is flaky #34561
• skip LongPollingTransportOnReceiveGetsCalled() because we can't quarantine Java tests, LongPollingTransportOnReceiveGetsCalled() is flaky #34563

[halter73]

| [6.375s] Microsoft.AspNetCore.Server.Kestrel.Connections Debug: Connection id "0HMAB2I8425HF" accepted.
| [10.059s] Microsoft.AspNetCore.Server.Kestrel.Connections Debug: Connection id "0HMAB2I8425HF" started.

[20.479s] Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware Debug: Authentication of the HTTPS connection timed out.

It looks like there might have been some serious threadpool starvation for the "accepted" and "started" logs to be ~4 seconds apart. The only thing between those two logs is a threadpool dispatch. I think that's what caused the handshake timeout and failed test.

"Accepted" log:

aspnetcore/src/Servers/Kestrel/Core/src/Internal/ConnectionDispatcher.cs

Lines 61 to 64 in 67deada

	Log.ConnectionAccepted(connection.ConnectionId);
	KestrelEventSource.Log.ConnectionQueuedStart(connection);
	ThreadPool.UnsafeQueueUserWorkItem(kestrelConnection, preferLocal: false);

Which immediately dispatches to the "started" log:

aspnetcore/src/Servers/Kestrel/Core/src/Internal/Infrastructure/KestrelConnectionOfT.cs

Lines 32 to 46 in 67deada

	void IThreadPoolWorkItem.Execute()
	{
	_ = ExecuteAsync();
	}
	internal async Task ExecuteAsync()
	{
	var connectionContext = _transportConnection;
	try
	{
	KestrelEventSource.Log.ConnectionQueuedStop(connectionContext);
	Logger.ConnectionStart(connectionContext.ConnectionId);
	KestrelEventSource.Log.ConnectionStart(connectionContext);

I'm not sure we should be quarantining tests because of threadpool starvation caused by who-knows-what. This seems to just be the unlucky victim.

[dougbu]

I'm not sure we should be quarantining tests because of threadpool starvation caused by who-knows-what. This seems to just be the unlucky victim.

Other tests in this class succeeded and the ThreadPool must not have been completely maxed out for that to happen. Is the timeout specified somewhere in the test❔ More generally, are you adding info for #34561 or suggesting a change to this PR❔

[dougbu]

Never mind @halter73. Do as you wish w/ #34561; I suggest upping timeouts used in the test(s) if possible.