add more TLS handshake test variations

[wfurt]

This is a follow-up on #1146 as I was trying to explain some observed discrepancies - primarily on Linux. The "Default" handshake uses 4K RSA key so it should be comparable to TLS12HandshakeRSA4096CertAsync on platforms without TLS1.3. For some reason using NetwrokStream with TCP is MUCH slower on Linux. I would expect pipe to be somewhat more efficient but not as much as observed.

DefaultHandshake may not be directly comparable across platforms as the setting may be different but it shows what we can do in the default setting.

Windows:

Method	Mean	Error	StdDev	Median	Min	Max	Gen 0	Gen 1	Gen 2	Allocated
DefaultHandshakeIPv4Async	770.9 us	12.38 us	11.58 us	770.8 us	747.2 us	785.8 us	2.9762	-	-	13.63 KB
DefaultHandshakeIPv6Async	719.7 us	3.44 us	3.05 us	719.9 us	714.4 us	726.1 us	2.9762	-	-	13.63 KB
DefaultHandshakePipeAsync	777.0 us	4.04 us	3.59 us	776.3 us	772.4 us	783.9 us	2.9762	-	-	15.82 KB
TLS12HandshakeECDSA256CertAsync	4,193.9 us	33.50 us	31.34 us	4,189.1 us	4,152.5 us	4,249.6 us	-	-	-	18.81 KB
TLS12HandshakeRSA1024CertAsync	3,646.8 us	15.63 us	13.85 us	3,644.5 us	3,616.3 us	3,670.7 us	-	-	-	19 KB
TLS12HandshakeRSA2048CertAsync	4,499.5 us	29.26 us	25.93 us	4,500.3 us	4,462.8 us	4,557.9 us	-	-	-	19.39 KB
TLS12HandshakeRSA4096CertAsync	10,820.1 us	208.02 us	213.62 us	10,725.9 us	10,599.2 us	11,255.1 us	-	-	-	20.13 KB

All Stream types are similar, TLS12 is slower because NewGuid() prevents TLS resume.

Now, on comparable Ubuntu machine:

Method	Mean	Error	StdDev	Median	Min	Max	Gen 0	Gen 1	Gen 2	Allocated
DefaultHandshakeIPv4Async	54.752 ms	1.0489 ms	1.0772 ms	55.291 ms	52.255 ms	56.391 ms	-	-	-	21.68 KB
DefaultHandshakeIPv6Async	53.936 ms	1.7093 ms	1.9685 ms	54.417 ms	48.620 ms	55.728 ms	-	-	-	21.68 KB
DefaultHandshakePipeAsync	7.280 ms	0.0616 ms	0.0577 ms	7.281 ms	7.197 ms	7.387 ms	-	-	-	21.67 KB
TLS12HandshakeECDSA256CertAsync	1.921 ms	0.0500 ms	0.0575 ms	1.916 ms	1.807 ms	2.040 ms	-	-	-	24.8 KB
TLS12HandshakeECDSA512CertAsync	3.881 ms	0.1845 ms	0.2125 ms	3.858 ms	3.626 ms	4.287 ms	-	-	-	24.99 KB
TLS12HandshakeRSA1024CertAsync	1.775 ms	0.0401 ms	0.0461 ms	1.782 ms	1.689 ms	1.848 ms	-	-	-	24.98 KB
TLS12HandshakeRSA2048CertAsync	2.278 ms	0.0350 ms	0.0328 ms	2.279 ms	2.234 ms	2.341 ms	-	-	-	25.37 KB
TLS12HandshakeRSA4096CertAsync	7.736 ms	0.1815 ms	0.2090 ms	7.750 ms	7.376 ms	8.223 ms	-	-	-	26.12 KB

Doing the same work over NetworkStream is MUCH slower. This is on the already connected socket so the cost of TCP handshake should not matter.

For comparison, when I run this with experimental TLS resume code I get:

Method	Mean	Error	StdDev	Median	Min	Max	Gen 0	Gen 1	Gen 2	Allocated
DefaultHandshakeIPv4Async	44.543 ms	0.4213 ms	0.3941 ms	44.469 ms	43.878 ms	45.385 ms	-	-	-	19.53 KB
DefaultHandshakeIPv6Async	44.774 ms	0.8421 ms	0.8648 ms	44.351 ms	43.728 ms	46.600 ms	-	-	-	19.66 KB
DefaultHandshakePipeAsync	1.831 ms	0.0819 ms	0.0943 ms	1.861 ms	1.530 ms	1.918 ms	-	-	-	19.63 KB

On Pipe the time goes from 7.2 -> 1.9 but TCP still steys pretty high -> much higher then the cost of crypto.

cc: @alnikola @tmds @stephentoub @adamsitnik

[stephentoub]

For some reason using NetwrokStream with TCP is MUCH slower on Linux

On Unix, NamedPipeClient/ServerStream uses a Socket under the covers, just with AddressFamily.Unix. So to clarify, this isn't actually about NetworkStream, but rather about whether the underlying Socket is connected over IPv4, IPv6, or UDS, right?

[wfurt]

yes. That is my assumption unless there is something wrong with NetwrokStream itself.
I plan to add more tests for sockets but I wanted to share some results.

[adamsitnik]

LGTM!