[coordinator] Duplicate implementation in VC an Verifier manager

[liran-funaro]

The code for both managers is largely duplicated, with only minor adaptations between them.
Both managers provide the same core functionality.

This issue proposes extracting the shared logic in order to:

• Eliminate code duplication
• Reduce the overall code size and maintenance overhead
• Enable bug fixes (such as [coordinator] VC manager stream end handling #608) to be implemented in a single place instead of multiple locations
• Improve code clarity by separating management logic from service-specific logic
• Simplify future enhancements by centralizing common behavior
• Improve maintainability and reduce the likelihood of behavioral drift between the two managers over time

It is also worth noting that the current implementation was originally approved under time constraints.
Under normal circumstances, code with this level of duplication and mixed responsibilities would likely not be accepted as-is.

In addition, the VC manager currently has an extra responsibility: storing the shared, load-balanced VC connection.
This issue proposes moving that responsibility into a separate class, since it is unrelated to task management and violates separation of concerns.

[cendhu]

Thanks for opening this.

I agree there is duplication between the VC manager and verifier manager, but I see this more as semantic duplication than pure code duplication.

If this were only mechanical code duplication, I would agree with extracting common logic. But these managers are part of the coordinator’s core logic, and their behavior is subtle:

• VC and verifier have different responsibilities
• Their stream lifecycle and recovery behavior are correctness-critical.
• VC sends statuses to the coordinator and validated nodes back to the dependency graph.
• Verifier only sends verified nodes forward.
• Policy update timing differs between verifier and VC.
• VC also has setup/query APIs through a shared VC connection.

Because of this, I prefer keeping the flow explicit. Having the logic visible in each manager makes it much easier to build a mental model, read the code, and debug failures. A generic service manager would hide important behavior behind adapter methods, which makes this core path harder to reason about.

For non-core or purely mechanical duplication, abstraction would be fine. But for this coordinator path, I’m okay with some semantic duplication if it keeps the logic readable and auditable.