Harden IPv6Any error handling

[Tratcher]

Fixes flaky test #43548

This test starts the server and expect a NotSupportedException due to some TLS options we don't support with HTTP/3(Quic).

Buggy flow:

• Bind to IPv6Any for Sockets / HTTP1 & 2
• Bind to IPv6Any for Quic, throw NotSupportedException when setting up TLS
• AnyIPListenOptions catches the Exception and tries to rebind to IPv4Any for Sockets instead. However, we were just on that port so we'll often get a conflict.

Fix: Don't fall back to IPv4Any for a NotSupportedException.

I also cleaned up some log statements and adjusted the port scanning to skip around more and avoid conflicts with other tests.

[adityamandaleeka]

cc @amcasey

[Tratcher]

@JamesNK ?

[JamesNK]

This isn't a strong guarantee, i.e. someone could change the exception thrown without realizing they change behavior here.

Is there test coverage for this?

[Tratcher]

Well, there's this test 😁

[amcasey]

Is this the behavior we want for all NotSupportedExceptions? If not, would it make more sense to throw a subtype?

[Tratcher]

We avoid defining custom exception types without an explicit need. We can reconsider if we find a conflict. We could compare the messages if we're paranoid.