eventcollector: dispatcher session management is coupled with statistics tracking in dispatcherStat

Problem

In the current implementation, dispatcherStat is responsible for both:

1. Connection lifecycle management — tracking which event service the dispatcher is registered to (dispatcherConnState), handling ready/not-reusable signal events, managing remote candidates, and coordinating registration/reset/remove flows.
2. Statistics and event processing — tracking checkpoint ts, epoch state, commit ts deduplication, and processing incoming data events.

This coupling makes the code harder to reason about. The connection state (connState) fields are accessed both from lifecycle coordination logic and from data event handling paths, making it difficult to understand the invariants of each subsystem independently.

Solution

Introduce a dispatcherSession type to encapsulate all connection lifecycle logic:

• Ownership of dispatcherConnState (event service ID, ready state, remote candidates)
• registerTo / commitReady / reset / remove / removeFrom operations
• handleSignalEvent for TypeReadyEvent / TypeNotReusableEvent

dispatcherStat retains ownership of statistics and event processing, and delegates all session-related operations to dispatcherSession via a session field.

This separation makes each type's responsibility clear and easier to test independently.

Start by locating dispatcherStat and trace its dispatcherConnState access, then inspect the registerTo, commitReady, reset, remove, removeFrom, and handleSignalEvent paths. Separate those lifecycle operations into dispatcherSession while keeping checkpoint, epoch, commit deduplication, and data-event processing in dispatcherStat; done means dispatcherStat delegates session behavior through its session field and the two responsibilities can be tested independently.