fix: allow sharing RocketMQ MQClientInstance to avoid thread explosion

[daguimu]

Problem

RocketMQUtils.getInstanceName appends System.nanoTime() to every generated client name, so every consumer and producer ends up with a unique instanceName and therefore a unique clientId (ip@instanceName). RocketMQ's MQClientManager.getOrCreateMQClientInstance creates a separate MQClientInstance per unique clientId, and each instance spawns ~20-24 threads (Netty EventLoop, PullMessageService, RebalanceService, ScheduledExecutor, etc.). With many stream bindings (e.g. 70+ consumers in the reported case) this multiplies into ~1,700 RocketMQ threads where one shared instance would be sufficient.

Root Cause

Consumers with different groups connecting to the same name server can safely share a single MQClientInstance — the consumerTable inside MQClientInstance is keyed by group. The nanoTime suffix defeats that sharing unconditionally, even when the binding topology would tolerate it.

Fix

• Add an opt-in shareClientInstance boolean to RocketMQCommonProperties (default false, so behavior is unchanged unless the user sets it).
• Add RocketMQUtils.getInstanceName(rpcHook, identify, shareClientInstance). When shareClientInstance is true, the nanoTime segment is omitted and the generated name becomes deterministic ([ak|]identify|pid), which lets RocketMQ reuse a single MQClientInstance across multiple consumers/producers in the same JVM.
• Keep the existing two-argument getInstanceName as a thin delegate so any external callers and the existing default behavior are preserved.
• Propagate shareClientInstance from RocketMQBinderConfigurationProperties to the consumer/producer properties inside mergeRocketMQProperties using OR-logic, so users can toggle the flag once at the binder level.
• Route the flag through RocketMQConsumerFactory#initPushConsumer, RocketMQConsumerFactory#initPullConsumer, and RocketMQProduceFactory so every produced/consumed client honors it.

Users who hit the thread explosion can now set:

spring:
  cloud:
    stream:
      rocketmq:
        binder:
          share-client-instance: true

or scope it per-binding on consumer/producer properties.

Tests Added

New unit tests in RocketMQUtilsTest:

Change Point	Test
Default overload keeps pre-existing per-call uniqueness	getInstanceNameWithoutSharingProducesDistinctNames, getInstanceNameWithoutSharingIncludesNanoTimeSuffix
New shareClientInstance=true mode yields deterministic names	getInstanceNameWithSharingProducesDeterministicNameForSameIdentify, getInstanceNameWithSharingOmitsNanoTimeSuffix
Shared names still differentiate by identify	getInstanceNameWithSharingStillDifferentiatesByIdentify
Access-key segment still prepended when an AclClientRPCHook is supplied	getInstanceNameWithRpcHookPrependsAccessKey
Two-arg overload delegates to the unshared path	defaultOverloadDelegatesToUnsharedBehavior
mergeRocketMQProperties OR-logic for the new flag	mergeRocketMQPropertiesPropagatesShareClientInstanceFromBinder, mergeRocketMQPropertiesPreservesConsumerShareClientInstanceWhenBinderIsFalse, mergeRocketMQPropertiesDefaultLeavesShareClientInstanceFalse

Impact

• Default behavior is unchanged (shareClientInstance=false), so existing applications pick up no behavioral drift.
• Applications with many RocketMQ stream bindings can opt in to collapse per-binding MQClientInstance copies into one, recovering the ~20 threads each duplicate would spawn.
• Changes are confined to the RocketMQ stream binder starter; no cross-module surface is altered.

Fixes #4291