Fix reentrant assert failures in session resumption with custom executions (#5844)

When `MsQuicLib.CustomExecutions` is enabled, all `MsQuicSetParam` calls
execute inline with `Connection->State.InlineApiExecution = TRUE` (see
`api.c:1666`). For `QUIC_PARAM_CONN_RESUMPTION_TICKET`, this triggers a
debug assertion failure at `connection.c:693`:

```c
CXPLAT_DBG_ASSERT(!Connection->State.InlineApiExecution || Connection->State.HandleClosed);
```

The assertion fires because `QuicConnIndicateEvent` is called while
`InlineApiExecution` is `TRUE` and `HandleClosed` is `FALSE`. Two
distinct call paths trigger this:

### Path 1: Via streams-available indication
```
MsQuicSetParam(QUIC_PARAM_CONN_RESUMPTION_TICKET)
  -> InlineApiExecution = TRUE
    -> QuicConnProcessPeerTransportParameters(FromResumptionTicket=TRUE)
      -> QuicStreamSetInitializeTransportParameters(FlushIfUnblocked=FALSE)
        -> QuicStreamSetIndicateStreamsAvailable
          -> QuicConnIndicateEvent  <-- ASSERT
```

### Path 2: Via datagram state change
```
MsQuicSetParam(QUIC_PARAM_CONN_RESUMPTION_TICKET)
  -> InlineApiExecution = TRUE
    -> QuicConnProcessPeerTransportParameters(FromResumptionTicket=TRUE)
      -> QuicDatagramOnSendStateChanged
        -> QuicConnIndicateEvent  <-- ASSERT
```

## Fix
Relax the assertion to not check app callback reentrancy when custom
execution is enabled, per suggestion by @guhetier.

Author: leikong

src/core/connection.c

@@ -692,11 +692,14 @@ QuicConnIndicateEvent(
         // MsQuic shouldn't indicate reentrancy to the app when at all possible.
         // The general exception to this rule is when the connection is being
         // closed because the API MUST block until all work is completed, so we
-        // have to execute the event callbacks inline.
+        // have to execute the event callbacks inline. Custom executions always
+        // have InlineApiExecution set, which makes this reentrancy check
+        // unreliable, so it is skipped for custom executions.
         //
         CXPLAT_DBG_ASSERT(
             !Connection->State.InlineApiExecution ||
-            Connection->State.HandleClosed);
+            Connection->State.HandleClosed ||
+            MsQuicLib.CustomExecutions);
         Status =
             Connection->ClientCallbackHandler(
                 (HQUIC)Connection,

src/core/stream.c

@@ -470,13 +470,16 @@ QuicStreamIndicateEvent(
         // or stream is being closed because the API MUST block until all work
         // is completed, so we have to execute the event callbacks inline. There
         // is also one additional exception for start complete when StreamStart
-        // is called synchronously on an MsQuic thread.
+        // is called synchronously on an MsQuic thread. Custom executions
+        // always have InlineApiExecution set, which makes this reentrancy
+        // check unreliable, so it is skipped for custom executions.
         //
         CXPLAT_DBG_ASSERT(
             !Stream->Connection->State.InlineApiExecution ||
             Stream->Connection->State.HandleClosed ||
             Stream->Flags.HandleClosed ||
-            Event->Type == QUIC_STREAM_EVENT_START_COMPLETE);
+            Event->Type == QUIC_STREAM_EVENT_START_COMPLETE ||
+            MsQuicLib.CustomExecutions);
         Status =
             Stream->ClientCallbackHandler(
                 (HQUIC)Stream,