fix(admin): coordinate initial URI and discovery configuration registration - #7888

Review: coordinate initial URI and configured discovery registration

This is a solid fix, and I checked the mechanism against the schema and the surrounding code rather than the description alone.

What I verified

• The takeover logic is correct. For a selector whose handler still points at the automatic LOCAL fallback, bindingDiscovery repoints the existing handler (updateSelective) to the configured discovery, keeps the discovery_rel row untouched, deletes the discovery_upstream rows by handler id, and only then removes the unreferenced fallback discovery row. Relation/handler identity is genuinely preserved, so nothing on the gateway side sees a new selector binding.
• The empty-registry case is covered. Clearing runtime state cannot rely on fetchAll alone: fetchAll no-ops when discoveryServiceCache has no entry for the discovery id, so removeSelectorUpstream is what guarantees the DELETE event fires. Calling it before createDiscovery is the right order — the DELETE lands, then the remote snapshot overwrites it.
• Lock order is consistent. registerDiscoveryConfig locks selector → plugin; registerDefaultDiscovery and registerURIWithLock lock only the selector. Nothing in the new code takes the plugin lock before a selector lock, and SelectorService#findByNameAndPluginNameAndNamespaceIdForUpdate (plugin lock first) is no longer on either path.
• The lock footprint is actually narrow, which is the part I expected to be a problem. selector has idx_selector_ns_plugin_name (namespace_id, plugin_id, selector_name), so findByNameAndPluginNameAndNamespaceIdForUpdate next-key-locks a single record instead of scanning. selectBySelectorIdForUpdate resolves through idx_discovery_rel_selector and joins discovery_handler by primary key, so it locks one rel row plus one handler row. selectByPluginNameAndLevelAndNamespaceIdAndTypeForUpdate uses idx_discovery_ns_plugin. This matters because FOR UPDATE on an unindexed predicate would have serialized every registration in the cluster — it does not.
• registerDefaultDiscovery returning null is handled at the only production call site. registerURIWithLock returns early before buildHandle/updateSelective, so no local upstream or handle mutation happens once a remote discovery owns the selector. The ShenyuException it now throws on namespace/plugin mismatch cannot fire on the URI path, because the selector is resolved by plugin name in the same statement.
• Transaction and event ordering hold: nativeCreateOrUpdate is a plain DB write with no event publication, updateSelective goes through the dispatcher's afterCommit, and doDiscoveryLocal now registers its publish after commit, so nothing is delivered for a rolled-back registration. testRolledBackUriRegistrationLeavesNoDiscoveryBinding pins exactly that.

The tests are unusually good for this area: arrival-order parameterization, two concurrent writers, an empty registry, rollback, and the independence assertion with a held selector lock all target real failure modes rather than coverage.

Non-blocking comments

1. doDiscoveryLocal no longer tolerates a null handler id. registerDefaultDiscovery is now nullable, and doDiscoveryLocal still does discoveryUpstreamDTO.setDiscoveryHandlerId(discoveryHandlerId) without a check (AbstractShenyuClientRegisterServiceImpl:316). Today it is safe only because the single caller returns early on null. Since the method is protected and now sits behind a nullable API, add a guard so a future second caller cannot insert upstreams with a null handler id.

2. The URI path resolves the default handler twice. registerURIWithLock calls registerDefaultDiscovery to decide whether a remote discovery owns the selector, then doDiscoveryLocal calls it again and pays two FOR UPDATE reads plus the handler/discovery lookups inside the same transaction. Passing the resolved handler id into doDiscoveryLocal (or splitting "resolve" from "ensure") removes a redundant round-trip on the registration hot path.

3. Fallback detection rests on a name convention. isDefaultLocalDiscovery matches discoveryLevel == SELECTOR && type == local && discoveryName == "<plugin>_default_discovery". That is the name registerDefaultDiscovery has always written, so it works today, but any manually created selector-level local discovery with that name would be silently repointed and its row deleted. Either reserve/document the name, or key the decision on something structural (the fallback always has handler == "{}" and no configured listener node).

4. A differing shared discovery is silently ignored. When a plugin-level discovery of the requested type already exists, the registering client's serverList is discarded in favour of the first one, with no log. Two clusters configured for the same plugin+nnamespace+type is a plausible misconfiguration, and it currently collapses silently — one WARN comparing serverList would save a debugging session.

5. selector.handle is left stale after a takeover. The promote path clears discovery_upstream and the runtime cache but deliberately does not rewrite the legacy selector.handle. The integration test shows the gateway ends up with only the remote instance, so behaviour is correct today; it is worth stating in the PR/README that the stale handle is intentional, otherwise someone will "fix" it later.

6. Nits: SelectorService#findByNameAndPluginNameAndNamespaceIdForUpdate now has no production caller (dead API — either drop it or keep it documented as external); the plugin row lock is also taken on the early-return "conflicting configuration" path where nothing is written; and pluginMapper.selectByNameForUpdate result is discarded, so a missing plugin silently skips the lock it was meant to provide.

LGTM otherwise. CI is still pending (11 checks), so I am not merging yet — I will re-check once the suite reports.

Re-approving: the only new commit since my last review is a merge with master, and the coordinated registration logic is unchanged.

The ordering still holds: the initial URI registration and the discovery configuration registration are reconciled before the selector is persisted, so a client cannot end up bound to a discovery handler that has not been created yet. The added selectByName/selectByIds mapper methods are namespace-scoped, and the tests cover both the immediate-activation and the reused-discovery paths.