feat(config): migrate config to sdk-proto and rebuild the listen state machine - #914

…proto

Signed-off-by: cxhello <caixiaohuichn@gmail.com>

Signed-off-by: cxhello <caixiaohuichn@gmail.com>

…-listener support

Replace the by-value cacheData stored in cache.ConcurrentMap with a
pointer-based configCacheHolder (clients/config_client/config_cache_holder.go),
fixing the long-standing bug where a second ListenConfig call on the same
dataId/group/tenant silently dropped the first listener instead of appending
to it.

- cacheData is now always referenced by pointer and carries its own mutex
  plus a listeners []*listenerWrap slice, so multiple independent listeners
  can be registered on the same key.
- ListenConfig now does get-or-create + an atomic reviveAndAddListener; an
  existing entry is revived (discard=false) rather than replaced, with the
  revive and the listener append happening in a single critical section so a
  concurrent CancelListenConfig can't interleave between them and leave the
  entry discard==true with a non-empty listeners slice. CancelListenConfig
  marks the entry discarded instead of removing it outright, and is a no-op
  on unknown keys.
- configCacheHolder.removeIfDiscarded re-checks discard && no-listeners under
  lock before deleting, so a concurrent revive/addListener can't race a
  removal.
- executeConfigListen/buildListenTask/refreshContentAndCheck and
  config_connection_event_listener.go/config_proxy.go are adapted to read
  from the holder; their single-batch listen=true behavior and per-listener
  notify-on-md5-change semantics are kept equivalent to today's behavior.
  Cancel-batch/listen=false executor semantics and real per-listener
  watermark delivery are left for follow-up tasks.
- Removed the dead ConfigClient.localConfigs field.

Signed-off-by: cxhello <caixiaohuichn@gmail.com>

…oup#629)

executeConfigListen now partitions each round into two independent
batches: discarded entries are sent as a Listen=false batch (grouped
by taskId) before any Listen=true batch, and are only reaped from the
holder via removeIfDiscarded once that batch gets a successful
response; a transport error or non-success response leaves them in
place for the next round to retry. This fixes CancelListenConfig never
actually telling the server to stop pushing a key.

Listen=true batches keep the existing changedConfigs handling
(refreshContentAndCheck) but now mark isSyncWithServer based on the
batch's own caches instead of the full holder snapshot, avoiding
cross-taskId contamination between concurrent batches.

Also make the config-change push handler ack cache misses with a
success response instead of returning nil, matching the documented
"push handler only marks isSyncWithServer=false and rings the bell"
contract.

Signed-off-by: cxhello <caixiaohuichn@gmail.com>

Add cacheData.notifyListeners(chain): snapshots md5/content/encryptedDataKey
and not-yet-caught-up listener wraps under cData.mu, then releases the lock
before running the filter chain and invoking callbacks. Each callback is
recover-wrapped so a panicking listener neither crashes the executor
goroutine nor blocks delivery to other listeners on the same key, and its
watermark only advances to the snapshotted md5 on a normal return -- a panic
leaves it unchanged so the content is replayed on the next round. A filter
chain error skips the whole round without advancing any watermark.

Replace the Task 3 interim notifyListenersIfChanged path (whole-entry,
fire-and-forget goroutines) with this per-listener delivery and rewire
refreshContentAndCheck to call cData.notifyListeners directly.

Signed-off-by: cxhello <caixiaohuichn@gmail.com>

ListenConfig previously registered a listener even after CloseClient
had already torn down the client's context and rpc connection,
leaving the caller with a listener that would never be served again.
Check isClosed under client.mutex at ListenConfig entry (same nacos-group#904
semantics used for naming) and return an error instead. Also add
regression coverage for CancelListenConfig and double CloseClient
staying panic-free after close.

Signed-off-by: cxhello <caixiaohuichn@gmail.com>

… coverage

Add TestIntegrationConfig{MultiListener,CancelStopsPush,CasPublish,
ListenSurvivesRestart} covering: two independent listeners on the same
key both firing on publish; CancelListenConfig actually stopping
further pushes (nacos-group#629); PublishConfig's CasMd5 rejecting stale writes
while leaving content untouched and accepting a correct cas (nacos-group#727);
and a listener surviving a full server restart (nacos-group#694). The restart
test is skipped unless NACOS_CONTAINER_NAME is set and shells out to
plain `docker restart`, matching reconnect_test.go's existing pattern.

Verified locally against both probe-nacos3 (3.2.0, port 8848) and
probe-nacos2 (2.5.2, port 8858) with -race -count=1.

Signed-off-by: cxhello <caixiaohuichn@gmail.com>

ListenConfig checked isClosed under client.mutex but committed the new
listener (getOrCreate + reviveAndAddListener) outside that lock, so a
CloseClient landing in between registered a live listener on an
already-shut-down client while still returning nil. Re-check isClosed
under client.mutex right after the commit and roll back via
cData.markDiscard() when a close won the race.

Export ErrConfigClientClosed (mirroring naming's
ErrFuzzyWatchClientClosed) and return it from both ListenConfig closed
paths so callers can errors.Is instead of matching error text.

Fix asyncNotifyListenConfig leaking a goroutine per call once the
client is closed: it blocked forever sending on listenExecute after
the listen executor loop had already exited via ctx.Done(). Select the
send against ctx.Done() too.

Signed-off-by: cxhello <caixiaohuichn@gmail.com>

TestListenConfigRaceWithCloseClientNeverLeavesLiveListenerOnClosedClient
asserted a <=10% threshold on how often a live listener survived a
nil-error ListenConfig racing CloseClient. That "benign occurrence"
rate is machine-dependent and flaked in CI (52/500 = 10.4% on GitHub
runners), so drop the percentage assertion entirely.

The ghost-listener semantics are already pinned deterministically by
TestListenConfigCommitRollsBackWhenCloseWinsRace. This test now keeps
only the concurrent ListenConfig/CloseClient hammer loop as a -race
exerciser for the Finding 1 locking, with scheduling-independent
invariants: the entry must never be observed with discard==true and
non-empty listeners, and once CloseClient has definitely returned, a
further ListenConfig call must fail with errors.Is(err,
ErrConfigClientClosed) and must not grow the listener count.

Signed-off-by: cxhello <caixiaohuichn@gmail.com>