Server does not receive initial DATAGRAM_STATE_CHANGED event

Describe the bug

Server does not seem to get the event which would advertise peers willingness to receive QUIC Datagrams. It only receives DATAGRAM_STATE_CHANGED events resulting from MTU changes via probes.

Affected OS

• Windows
• Linux
• macOS
• Other (specify below)

Additional OS information

No response

MsQuic version

main, 2.2 and others

Steps taken to reproduce bug

Client enables Datagram extension.

Added some code to log events received from MsQuic (on worker thread) to console + some logging from user thread.

async Task Run(bool clientAdvertised, bool serverAdvertised)
{
    System.Console.WriteLine($"Client advertised: {clientAdvertised}, server advertised: {serverAdvertised}");

    // connect client and server, unrelated boilerplate code omitted

    AssertProperties(serverAdvertised, client);
    AssertProperties(clientAdvertised, server);
}

static void AssertProperties(bool peerAdvertised, QuicConnection connection)
{
    // following properties are populated straight from the event handler which receives the associated events
    Console.WriteLine($"{connection}.DatagramSendEnabled: {connection.DatagramSendEnabled}, expected: {peerAdvertised}");
    Console.WriteLine($"{connection}.DatagramMaxSendLength: {connection.DatagramMaxSendLength}");
    Console.WriteLine();
}

await Run(true, false);

Expected behavior

Client advertised: True, server advertised: False
[conn][0x1B68367D6A0]: DATAGRAM_STATE_CHANGED: Enabled=1, Mtu =1196 // this event coming before CONNECTED
[conn][0x1B6838DB990]: DATAGRAM_STATE_CHANGED: Enabled=0, Mtu =0
[conn][0x1B6838DB990]: CONNECTED
[conn][0x1B68367D6A0]: CONNECTED
[conn][0x1B6838DB990].DatagramSendEnabled: False, expected: False
[conn][0x1B6838DB990].DatagramMaxSendLength: 0

[conn][0x1B68367D6A0].DatagramSendEnabled: True, expected: True     // makes our expectations true
[conn][0x1B68367D6A0]: DATAGRAM_STATE_CHANGED: Enabled=1, Mtu =1196
[conn][0x1B68367D6A0].DatagramMaxSendLength: 1196                   // and we know the MTU

[conn][0x1B68367D6A0]: DATAGRAM_STATE_CHANGED: Enabled=1, Mtu =1228

Actual outcome

The server connection (0x1B68367D6A0) Receives first the CONNECTED event, which makes us consider the connection fully ready for use by the user. Only after that, it receives DATAGRAM_STATE_CHANGED (debugger shows this one is caused by MTU discovery).

Client advertised: True, server advertised: False
[conn][0x1B6838DB990]: DATAGRAM_STATE_CHANGED: Enabled=0, Mtu =0
[conn][0x1B6838DB990]: CONNECTED
[conn][0x1B68367D6A0]: CONNECTED
[conn][0x1B6838DB990].DatagramSendEnabled: False, expected: False
[conn][0x1B6838DB990].DatagramMaxSendLength: 0

[conn][0x1B68367D6A0].DatagramSendEnabled: False, expected: True
[conn][0x1B68367D6A0].DatagramMaxSendLength: 0               // default value since this thread lost the race with the QUIC worker thread
[conn][0x1B68367D6A0]: DATAGRAM_STATE_CHANGED: Enabled=1, Mtu =1196

[conn][0x1B68367D6A0]: DATAGRAM_STATE_CHANGED: Enabled=1, Mtu =1228

Additional details

Some debugging shows that even though QuicConnProcessPeerTransportParameters is called for the server, by that time Connection->State.ExternalOwner is still false because it was not handed off to the userland yet.

I am aware that I can query the Datagram support via QUIC_PARAM_CONN_DATAGRAM_SEND_ENABLED, but I didn't find a way to query the Mtu size, so there is still a brief period of time where the server does not know the DatagramMaxSendLength and I don't want to use some arbitrary number by default.

Start at QuicConnProcessPeerTransportParameters and examine how Connection->State.ExternalOwner affects delivery of DATAGRAM_STATE_CHANGED during server connection setup. Reproduce the client/server sequence described in the issue, including the CONNECTED event and MTU probe events. Done means the server receives the initial peer-advertisement state and has the datagram MTU available without relying on a later probe event.