QUIC API: Consider passing QuicConnectionOptions to Quic.Connection.ConnectAsync

[geoffkizer]

We have a somewhat awkward API pattern today, where you pass the QuicConnectionOptions object to to QuicConnection constructor, but we don't actually use it until you do ConnectAsync. One minor inconvenience of this is that we have to store the QuicConnectionOptions object for this brief period of time when we don't use it any other time.

We should consider passing these options into ConnectAsync instead, to simplify the model and implementation here.

[ghost]

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

Issue Details

---

We have a somewhat awkward API pattern today, where you pass the QuicConnectionOptions object to to QuicConnection constructor, but we don't actually use it until you do ConnectAsync. One minor inconvenience of this is that we have to store the QuicConnectionOptions object for this brief period of time when we don't use it any other time.

We should consider passing these options into ConnectAsync instead, to simplify the model and implementation here.

Author:	geoffkizer
Assignees:	-
Labels:	area-System.Net.Quic
Milestone:	7.0.0

[ManickaP]

Moreover, as @scalablecory mentioned in our discussion, we shouldn't create QuicConnection via constructor since that would prevent us from making the class abstract in the future - if we decide to provide the abstraction. Instead, we could have a static method QuicConnection QuicConnection.ConnectAsync(QuicConnectionOptions options) to construct and connect the connection in one go.

[ManickaP]

Closing as covered by #68902 and #70424