quic test improvements

[wfurt]

This is test-only change

• Fix pattern when we can hang in AcceptAsync if client fails to connect
• plumb more ITestOutputHelper so we can capture more data on failures
• add some more timeouts in places
• restrict wildcard on Conformance tests so editor can create swap file without breaking build.

contributes to #55642

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This is test-only change

• Fix pattern when we can hang in AcceptAsync if client fails to connect
• plumb more ITestOutputHelper so we can capture more data on failures
• add some more timeouts in places
• restrict wildcard on Conformance tests so editor can create swap file without breaking build.

contributes to #55642

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Quic
Milestone:	-

[ManickaP]

Some small comments, otherwise LGTM, thanks!

[ManickaP]

Why don't you declare it as TimeSpan? You wouldn't need to add those overloads to TaskTimeoutExtensions.cs and you'd have avoided mistakes like WaitAsync(TimeSpan.FromSeconds(PassingTestTimeout)) - seconds instead of milliseconds. Unless you really want there super long timeout.

[wfurt]

Some tests suites have actually both - one created from the other. I may do that for consistency.

[geoffkizer]

SInce this is a common, repeated pattern, I wonder if we should have a helper method for it, like CreateClientAndServer or something like that. Or EstablishConnection or something.

We have RunClientServer, but that's not really the same.

[wfurt]

yah. I wanted to like SslStream. But if I return tuple we loose the using var.
We would need to than use good old

using (clientConn)
using (serverConn)
{
  ....
}

[wfurt]

BTW the helper would be also nice if we want to bet in any retry logs for the flaky listener if we don't find way how to fix it.

[geoffkizer]

Yeah, it's a little verbose because of the using stuff.

One idea would be to define something like

struct QuicConnectionPair : IDisposable
{
  public QuicConnection Client { get; }
  public QuicConnection Server { get; }
  public void Dispose() { Client.Dispose(); Server.Dispose(); }
}

public static ValueTask<ConnectionPair> EstablishConnectionAsync(...) { ... }

Then you can just write code like this:

  using (var connectionPair = await EstablishConnectionAsync(...);
  // use connectionPair.Client and connectionPair.Server here

If we feel really ambitious we could generalize ConnectionPair to something like DisposablePair<T1, T2>. And maybe add some implicit conversion ops from ValueTuple<T1, T2>...

@stephentoub already has something vaguely like this for the Stream Conformance Tests.