Threading refactor (2/7): SessionImpl — synchronized(lock) → SynchronizationContext

[igorbernstein2]

Summary

Phase 2 of 7. Replaces the per-SessionImpl Object lock with an explicit SynchronizationContext. Builds on the infrastructure introduced in [Phase 1].

The migration is staged so each step keeps tests green:

1. Add the syncContext alongside the existing lock.
2. Move RPC mutations onto it (startRpc / cancelRpc).
3. Remove the lock entirely.
4. Wire up uncaught-exception abort.

What's in here

Commit	What it does
chore: add session SynchronizationContext alongside the existing lock	sessionSyncContext serializes stream callbacks. onMessage/onClose dispatch onto it; the per-session heartbeat tick trampolines through it.
synchronized(lock) blocks remain inside the handlers — the two coexist for now. Affinity asserts added at boundary methods.
chore: make startRpc and cancelRpc async via sessionSyncContext	SessionImpl.startRpc and cancelRpc now submit to sessionSyncContext rather than running synchronously on the caller. VRpcSessionApi.startRpc
becomes void — errors flow through rpc.handleError() onto ctx.getExecutor().
chore: remove synchronized(lock) from SessionImpl	All session state mutations now run on sessionSyncContext, so the per-session Object lock is no longer needed. nextRpcId becomes AtomicLong for the
cross-thread newCall() caller. handleVRpcResponse / handleVRpcErrorResponse drop the localCancel/localRpc capture-and-recheck dance — sessionSyncContext serializes them now.
chore: abort session on uncaught exception in sessionSyncContext (+ closeReason synthesizer)	Split terminal close into notifyTerminalClose (per-target try/catch fan-out) and abortFromUncaughtException (global
handler). Uncaught syncContext exceptions always set closeReason to ERROR. notifyTerminalClose synthesizes a fallback closeReason if missing — defensive against future writers who forget. Adds three regression tests.

Stack position

• Base: threading-refactor-phase-1
• Next: threading-refactor-phase-3 — executor isolation (cached pool for user callbacks, gRPC DirectExecutor)

[nimf]

I guess it doesn't hurt to do it twice, but we just did it in the dispatchResponseMessage above.

Interestingly, for some branches in dispatchResponseMessage we add this duplication and for some don't, e.g., handleSessionParamsResponse, handleGoAwayResponse, handleSessionRefreshConfigResponse don't have it, while handleOpenSessionResponse, handleVRpcResponse, handleVRpcErrorResponse, and handleHeartBeatResponse do.