Support client cert negotation

[Tratcher]

Fixes #23948 @avparuch

Developers can now opt-in to using delayed client certificate negotiation via ClientCertificateMode.DelayCertificate on HttpsConnectionAdapterOptions. Note negotiation is always enabled if you're using the UseHttps overload that takes ServerOptionsSelectionCallback since there are no HttpsConnectionAdapterOptions passed there.

• POST mitigations
  • It looks like small bodies (~under 4kb) received with the initial request work because kestrel buffers it as part of parsing the headers.
  • Larger bodies cause System.InvalidOperationException: Received data during renegotiation.
  • The caller must buffer the request body before requesting the client cert. I've added a sample showing this.

[Tratcher]

Ok, that last commit changed things around a bit. I realized that ClientCertificateMode.DelayCertificate didn't work if used in the SNI from config code path. I was able to flow it through the internal code paths as a tuple. Thoughts?

[Tratcher]

Ok, that last commit changed things around a bit. I realized that ClientCertificateMode.DelayCertificate didn't work if used in the SNI from config code path. I was able to flow it through the internal code paths as a tuple. Thoughts?

I recommend refactoring these internals as part of #33452, but it shouldn't change the functionality in this PR.

[halter73]

Why not?

Suggested change

	&& !connectionItems.Items.TryGetValue("tls.clientcert.negotiated", out var _))
	&& (tlsFeature is not ClientCertBufferingFeature))

[Tratcher]

ClientCertBufferingFeature gets stored in the HttpContext's FeatureCollection, not the connection's FeatureCollection. It's reverted before the next request. Items persist across requests.

[halter73]

Do we have a test to verify we aren't renegotiating when NegotiatedApplicationProtocol is HTTP/2?

[Tratcher]

Added in the HTTP/2 HttpClient interop tests. That's one of the only places we test HTTP/2 over TLS.

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[Tratcher]

Awkward, the build passed but it never reported status here:
https://dev.azure.com/dnceng/public/_build/results?buildId=1189136&view=results

@dotnet/aspnet-build would you be so kind as to merge this?

[wtgodbe]

Yeah, github reporting has been weird today