[agent] Replace drbdsetup status polling with events2 state store

[astef]

Description

Replace per-reconcile drbdsetup status + drbdsetup show subprocess calls with an in-memory state store backed by the events2 stream, plus a lazy show cache for configuration data.

Two new components are introduced in the drbdr package:

• DRBDStateStore — thread-safe store of DRBD runtime state (role, disk-state, connections, paths, etc.), built incrementally from events2 by the Scanner. Provides Snapshot(resourceName) that returns a *drbdutils.Resource compatible with the existing actualState consumption.
• ShowCache — per-resource cache of drbdsetup show results (configuration options, backing disk, net options). Fetched lazily on first access, invalidated after convergence actions.

The reconciler's initial observe phase reads from the store + show cache (zero subprocess calls in steady state). The post-convergence refresh still calls drbdsetup status directly for immediate accuracy, then re-fetches show from the invalidated cache.

--statistics flag added to events2 args so size is available in device events.

Why do we need it, and what problem does it solve?

Every reconcile of a DRBDResource spawned 2 subprocesses (drbdsetup status + drbdsetup show), and up to 2 more after convergence. With 20 concurrent reconcilers and frequent events, this created excessive process overhead.

The events2 stream already carries all runtime state data — the same data that drbdsetup status returns. By maintaining this state in memory and reading from it during reconciliation, we eliminate redundant subprocess calls.

What is the expected result?

Subprocess calls per reconcile cycle:

Scenario	Before	After
Non-converging (steady state)	2 (status + show)	0 (first time: 1 show)
Converging	4 (status + show + refresh status + refresh show)	2 (refresh status + refresh show)
Orphan check	1 (status)	0
Rename recovery	1 (status)	0

Functional behavior is preserved — the same ActualDRBDState interface is used by downstream code (Report, computeTargetDRBDActions, etc.) with no changes.

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.