Make SDK and EventSubscribe shutdown idempotent

[Copilot]

Stopping or destroying Client / EventSubscribe could re-enter native shutdown on the same JNI-backed handle and crash the JVM in bcos_sdk_stop. This change tightens Java-side lifecycle handling so repeated shutdown paths do not double-stop or tear down shared native state out of order.

• Client lifecycle hardening

  • Make ClientImpl.start(), stop(), and destroy() synchronized and stateful.
  • Ignore repeated stop() / destroy() calls after the first effective shutdown.
  • Prevent repeated native RpcJniObj.stop() / BcosSDKJniObj.destroy(...) on the same client handle.

• Event subscription ownership model

  • Distinguish between:
    • EventSubscribe.build(group, config) → owns the internally created client
    • EventSubscribe.build(client) → borrows the caller-provided client
  • Only delegate shutdown/destruction to the client when the EventSubscribe instance owns it.
  • Avoid directly destroying the JNI event wrapper when it aliases the client's native SDK handle.

• Safer EventSubscribe shutdown

  • Make EventSubscribeImp.stop() / destroy() idempotent.
  • Unsubscribe active events before shutdown to reduce teardown races with in-flight native event state.
  • Return an empty set when querying subscribed events after teardown instead of exposing null behavior.

• Focused regression coverage

  • Add unit tests covering repeated ClientImpl.stop() / destroy().
  • Add unit tests covering shared-client vs owned-client EventSubscribe shutdown behavior.

Example of the intended behavior:

EventSubscribe sub = EventSubscribe.build(client);

sub.stop();
sub.stop();      // no-op

sub.destroy();
sub.destroy();   // no-op

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud