A controller call's on-complete handler may run managed code, so it must
be dispatched by the Session under a ManagedCodeTaskGroup token, not
invoked directly by the ControllerAccess (which previously held it as a
plain callable and called it itself -- untokened and undispatched).
Wrap it in an opaque ControllerAccess::OnControllerCallReturn that
implementations can hold but not call. They complete it via exactly one
of three Session-provided paths:
- handleControllerCallResult -- the controller returned a result;
dispatches the handler under a fresh token. Asserts the managed-code
group is still open (i.e. before notifyDisconnected).
- failPendingControllerCall -- an already-enqueued call is failed
because the connection dropped before a result arrived (the disconnect
drain); dispatches the handler under a token with a disconnect error.
- failControllerCallInline -- a call made from within callController
while already disconnecting, which can never be enqueued; runs the
handler inline with a disconnect error, where the caller (and its token)
is still on the stack.
Together these guarantee a controller call's handler always runs exactly
once, with a result or a disconnect error, and never runs managed code
without a token. Only the success path takes a result value; the two
failure paths produce the canonical disconnect error internally, so it
can't be gotten wrong. InProcessControllerAccess and the Session unit
tests are updated.
5602b98193