fix: prevent duplicate TCP bootstrap server creation

[lymerin]

Fixes #6735.

What is changed

TcpProxySelectorDataHandler previously used a non-atomic check-then-act sequence:

inCache -> createBootstrapServer -> cache

Concurrent selector synchronization events could both observe a cache miss and start bootstrap servers for the same selector. This could cause port binding failures or leave an overwritten server and its event-loop resources without lifecycle management.

This change:

• adds per-selector single-flight creation in TcpBootstrapFactory;
• ensures concurrent creation requests for the same selector wait for one in-flight creation;
• performs server startup outside ConcurrentHashMap atomic callbacks and without a global lifecycle lock;
• allows different selectors to be created and removed independently;
• uses putIfAbsent when publishing the started server and shuts down a losing instance if another server was already cached;
• routes TcpProxySelectorDataHandler through the atomic creation and removal methods;
• preserves the existing public factory methods for compatibility;
• rolls back LoopResources when bootstrap startup fails;
• makes TcpBootstrapServer.shutdown() idempotent and preserves shutdown failures using suppressed exceptions.

The change is limited to the duplicate bootstrap creation and related resource lifecycle described in #6735. Existing selector configuration update behavior is unchanged.

Tests

Added or extended tests covering:

• concurrent creation of the same selector creates only one server;
• a failed creation can be retried;
• waiting callers receive the original creation failure;
• slow shutdown of one selector does not block removal of another selector;
• bootstrap startup failure disposes its loop resources;
• repeated shutdown is idempotent;
• failures from both server and loop-resource disposal are preserved.

The following targeted Maven build passed locally:

mvn -pl shenyu-protocol/shenyu-protocol-tcp,shenyu-plugin/shenyu-plugin-proxy/shenyu-plugin-tcp \
    -am \
    -Dtest=TcpBootstrapFactoryTest,TcpBootstrapServerTest,TcpProxySelectorDataHandlerTest \
    -Dsurefire.failIfNoSpecifiedTests=false \
    test

Results:

• TcpBootstrapServerTest: 11 tests passed
• TcpBootstrapFactoryTest: 4 tests passed
• TcpProxySelectorDataHandlerTest: 3 tests passed
• Checkstyle: no violations

Checklist

• I have read the [contribution guidelines](https://shenyu.apache.org/community/contributor-guide).
• I have submitted test cases that cover the changes.
• I have run the complete ./mvnw clean install -Dmaven.javadoc.skip=true build.

[Aias00]

Review: Prevent duplicate TCP bootstrap server creation (#6735)

Verdict: APPROVE

Analysis

Solid, well-tested fix addressing three related issues in the TCP bootstrap lifecycle.

1. Duplicate-creation guard (TcpBootstrapFactory)

• Introduces a creations ConcurrentMap<String, CompletableFuture<BootstrapServer>> to track in-flight creations.
• createBootstrapServerIfAbsent:
  • cache.containsKey fast path returns false if already present.
  • creations.putIfAbsent ensures only one thread performs creation; concurrent callers awaitCreation (which correctly unwraps CompletionException to the original cause) and return false.
  • Double-checked cache.get after winning the creation future; if another server already landed, the new one is shutdown() (no leak) and the existing is returned.
  • On RuntimeException, completeExceptionally + rethrow, with finally doing creations.remove(selectorName, creation) (atomic, value-checked cleanup). getCache exists (verified) and createBootstrapServer calls start() internally, so a bind failure propagates and the partially-built server is discarded correctly.
• removeAndShutdown is idempotent (no-op when absent).

2. Resource leak on bind failure (TcpBootstrapServer.start)

• start() now wraps bindNow() in try/catch; on failure it disposes the LoopResources (which was already assigned to the field before bind) before rethrowing. No leaked event-loop resources.

3. Idempotent / safe shutdown (TcpBootstrapServer.shutdown)

• Now synchronized with a disposed guard, so repeated shutdown is a no-op. Both server and loopResources are null-guarded, and failures are collected with addSuppressed so no exception is silently swallowed.

Tests: TcpBootstrapServerTest + TcpBootstrapFactoryTest cover concurrent-single-creation, retry-after-failure, failure unwrapping, non-blocking removal of a different selector during shutdown, loop-resource disposal on bind failure, single shutdown, and exception propagation on disposal failure. Coverage is thorough.

Conclusion

The concurrency model is correct, imports are clean (no leftover unused imports in TcpProxySelectorDataHandler), and the edge cases are exercised. Approving.