client: introduce ConnectionManager to fix reconnect/disconnect panics

[dave-tucker]

Add a ConnectionManager (CM) — a finite-state machine goroutine that
owns all OVSDB connection lifecycle and proxies RPC calls, eliminating
the data races and panics that occurred when concurrent callers triggered
reconnect and disconnect simultaneously.

ConnectionManager (client/connection.go):

• New FSM with three states: Disconnected, Connecting, Connected.
• Single run-loop goroutine that serialises all state transitions;
  commands arrive on a buffered cmdCh and responses on per-command reply
  channels.
• Server-push notifications (update/update2/update3) are forwarded to the
  client event loop via a 64-slot eventCh so the rpc2 callback returns
  immediately and never blocks on cache work.
• Inactivity probing, leader-only mode, and multi-endpoint failover are
  all handled inside the CM run loop, removing the goroutine-per-concern
  races present in the previous implementation.
• Close() keeps the CM alive in drain mode so in-flight commands receive
  ErrNotConnected rather than blocking; Connect() after Close() restarts
  the event loop cleanly.

client.go / event loop:

• runEventLoop() reads from eventCh and dispatches:
  EventDisconnected — purges cache, sets deferUpdates=true
  EventReconnected — re-applies schema and reestablishes monitors
  EventInboundRPC — applies update/update2/update3 to the cache
• waitForCacheConsistent() polls deferUpdates under cacheMutex.RLock so
  Get/List/etc. block until the post-reconnect monitor replay finishes.

Bug fixes:

• Close() deadlock when reestablishMonitors was in-flight.
• Close() hang when cache event handlers blocked on shutdown.
• Connect() after Close() failing to restart the event loop.
• Data race in DatabaseModel/Mapper accessed without modelMutex.

Integration test fixes:

• Reset model struct on each Eventually iteration: model.CloneInto uses
  json.Unmarshal which merges into existing maps rather than replacing
  them; a fresh struct on each poll ensures deleted map keys do not
  survive across attempts (TestMultipleOpsTransactIntegration,
  TestMultipleOpsSameRow).
• Increase TestMultipleOpsSameRow Eventually timeout from 2s to 5s; the
  two-transact setup needs more headroom on slower OVS 3.x runners.
• Add explicit cache-consistent waits after Transact calls in tests that
  assert immediate cache state.