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.

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

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.

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)
{
  ....
}

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.

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.