…ocket.conf (apache#20840)

Motivation: Since the PR apache#16234 add the prop `cryptoKeyReaderFactoryClassName` for the WebSocket Proxy, but did not add this prop to `websocket.conf`.  This can make the script which try to replacement attribute a bit difficult to write

Modifications: add the conf `cryptoKeyReaderFactoryClassName` into the file `websocket.conf`

…all and canal.client-1.1.5 (apache#20792)

…ry (apache#20823)

… OOM (apache#20837)

…20843)

…che#20783)

…he#20850)

…ransactionBufferInternalStats API (apache#20330)

master apache#20291

### Motivation

Our primary goal is to improve the visibility and troubleshooting capabilities of the Pulsar Transaction Buffer by providing more detailed information about the snapshot stats and system topic internal status.
### Modifications

1. Enhance the existing TransactionBufferStats by adding information about snapshot stats, including the capital of the current segment, unseal aborted transaction ID size, and other related data. This will provide better visibility and troubleshooting capabilities for the Pulsar Transaction Buffer.
2. Introduce a new API for obtaining TransactionBufferInternalStats, allowing users to access the state of the system topic used for storing snapshots. This will facilitate problem investigation and resolution when issues arise with the transaction buffer.

…apache#20713)

Sasl authentication has two phases. In the first phase, the broker will temporarily cache the authentication info, and clean the cache at the end of the second phase.
When the client crashes after phase 1, or someone deliberately attacks, the auth info will always remain in the broker's memory.
If the client keeps reconnecting like this, the broker will soon OOM.

…custom authz provider (apache#20848)

…om bundle (apache#20846)

…apache#20800)

Co-authored-by: tison <wander4096@gmail.com>

… API compatibility (apache#20826)

…hed` (apache#20855)

…pache#20876)

Signed-off-by: tison <wander4096@gmail.com>

…e#20858)

### Motivation

Add `Audience.Private` annotation for topic compaction strategy. Since this interface only uses for load manager, other users should not use this interface.

…ndalone (apache#20709)

Fixes : apache#20617

### Motivation

Currently, clients' shutdown API does not behave consistently in sense that asynchronicity is not handled explicitly. So issue apache#20617 happens.

This PR will allow clients know that shutdown is actually triggered.

### Modifications

- Synchronize call to `POST /shutdown` on client side
- Asynchronize explicitly `pulsar().closeAsync()` invocation

…k rule (apache#20560)

apache#20887)

…apache#20627)

…egistered if there has no message was sent (apache#20888)

Motivation: In the replication scenario, we want to produce messages on the native cluster and consume messages on the remote cluster, the producer and consumer both use a same schema, but the consumer cannot be registered if there has no messages in the topic yet.The root cause is that for the remote cluster, there is a producer who has been registered with `AUTO_PRODUCE_BYTES` schema, so there is no schema to check the compatibility.

Modifications: If there is no schema and only the replicator producer was registered, skip the compatibility check.

…r. (apache#20880)

Main Issue: apache#20851
### Motivation
When the Proto version does not allow us to send TcClientConnectRequest to the broker, we should add a log to debug it.

### Modifications

Add a waining log.

…edup and set namespace disable deduplication. (apache#20905)

### Motivation

- The task `trim ledgers` runs in the thread `BkMainThreadPool.choose(ledgerName)`
- The task `write entries to BK` runs in the thread `BkMainThreadPool.choose(ledgerId)`

So the two tasks above may run concurrently/

The task `trim ledgers` work as the flow below:
- find the ledgers which are no longer to read, the result is `{Ledgers before the slowest read}`.
- check if the `{Ledgers before the slowest read}` is out of retention policy, the result is `{Ledgers to be deleted}`.
  - if the create time of the ledger is lower than the earliest retention time, mark it should be deleted
  - if after deleting this ledger, the rest ledgers are still larger than the retention size, mark it should be deleted
- delete the`{Ledgers to be deleted}`

**(Highlight)** There is a scenario that causes the task `trim ledgers` did  discontinuous ledger deletion, resulting consume messages discontinuous:
- context: 
  - ledgers: `[{id=1, size=100}, {id=2,size=100}]`
  - retention size: 150
  - no cursor there
- Check `ledger 1`, skip by retention check `(200 - 100) < 150`
- One in-flight writing is finished, the `calculateTotalSizeWrited()` would return `300` now.
- Check `ledger 2`, retention check `(300 - 100) > 150`, mark the ledger-2 should be deleted.
- Delete the `ledger 2`.
- Create a new consumer. It will receive messages from `[ledger-1, ledegr-3]`, but the `ledger-2` will be skipped.

### Modifications

Once the retention constraint has been met, break the loop.

…ache#20914)

…ache#20917)

…d close producer/consumer (apache#20956)

…AuthorizationProvider plugin (apache#20939)

Fixed apache#20938

… `ArrayDeque` instead of `Stack` (apache#20808)

…pache#20952)

### Motivation

Minor improve `getIsolationGroup` by avoid creating arrayList. And it'  beneficial to GC

### Modifications

`new HashSet<>(Arrays.asList(...))` -> `Sets.newHashSet(...)`

Signed-off-by: tison <wander4096@gmail.com>

…pache#20943)

…API when bookie-rack is not configured. (apache#20949)

…tadata not found (apache#20979)

…20978)