[improve][test] Migrate pulsar-perf to the V5 client API - #25887

…5 ones

### Motivation

`pulsar-perf` was migrated to the V5 client API in apache#25887 (and apache#25917 did the
same for `pulsar-client`), so every perf subcommand now drives the V5 SDK.
That leaves no way to benchmark the v4 client, or v4 (non-scalable) topics,
without the V5 SDK in the path — and several v4 capabilities became
unreachable, because they have no V5 equivalent:

- `--max-outstanding` / `--max-outstanding-across-partitions` and round-robin
  partition routing on the producer;
- real `Exclusive` / `Failover` / `Key_Shared` subscription types,
  `MessageListener` dispatch on the client's listener threads, pooled messages,
  batch-index acknowledgment, the chunked-message knobs, the receiver-queue
  limits and the auto-scaled receiver-queue reporting on the consumer;
- the v4 `Reader` itself — `read` measures a V5 `CheckpointConsumer`, a
  different broker-side entity — along with a `lid:eid` start message id,
  `--receiver-queue-size` and `--use-tls`;
- the v4 transaction coordinator, which stays a live broker code path next to
  the v5 one (PIP-473 P5.4) with nothing driving it, and its acknowledgement
  round-trip latency (V5's `acknowledge` is a synchronous void, so its reported
  ack latency is a local measurement).

### Modifications

Each benchmark is split into an abstract base holding everything that is not
client-specific — the CLI options, the throughput/latency accounting, the
run() skeleton and message loop, and the reports — plus two thin subclasses
that bind the client types: the existing V5 command, and a new v4 one.

    PerformanceProducerBase    -> PerformanceProducer     / PerformanceProducerV4     (produce-v4)
    PerformanceConsumerBase    -> PerformanceConsumer     / PerformanceConsumerV4     (consume-v4)
    PerformanceReaderBase      -> PerformanceReader       / PerformanceReaderV4       (read-v4)
    PerformanceTransactionBase -> PerformanceTransaction  / PerformanceTransactionV4  (transaction-v4)

This is a split rather than a revert, so the bases keep the improvements made
since the migration — instance recorders, the 3-significant-digit histograms
and the latency clamps from apache#26466, class-based subcommand registration from
apache#26467 — and both commands share one benchmark and one set of measurements.
The v4 commands offer the same flags as their V5 counterparts (only the
V5-only `--scalable-consumer-type` and `--scalable` are not mirrored).

Each base logs through a logger named after the concrete subclass, so the
report lines keep naming the subcommand that produced them.

Where the two clients genuinely differ, the seam is explicit: the v4 consumer
and reader keep `MessageListener`/`ReaderListener` dispatch while V5 keeps its
poll threads; the v4 producer does not await a transaction's sends before
committing (V5 must, because its transactional sends are queued onto an
internal dispatch chain); only the first transaction of a V5 test thread waits
out the coordinator's asynchronous connect, so the rollover loop still counts
every failed open.

`--jsse-provider` / `--jca-provider` are also wired into the v4 client builder,
which previously read them only for the admin and V5 legs.

### Verifying this change

New unit and end-to-end tests in `pulsar-testclient` cover subcommand
registration and naming, conf-file defaults and case-insensitive enums on the
v4 commands, the shared `-st` enum mapping onto the v4 client enum, produce /
consume / read round trips through the v4 commands, the `lid:eid` start
position, and the v4-only producer knobs. `PerfToolTest` gains v4 cases that
run the commands from `bin/pulsar-perf` in a container.

…5 ones

### Motivation

`pulsar-perf` was migrated to the V5 client API in apache#25887 (and apache#25917 did the
same for `pulsar-client`), so every perf subcommand now drives the V5 SDK.
That leaves no way to benchmark the v4 client, or v4 (non-scalable) topics,
without the V5 SDK in the path — and several v4 capabilities became
unreachable, because they have no V5 equivalent:

- `--max-outstanding` / `--max-outstanding-across-partitions` and round-robin
  partition routing on the producer;
- real `Exclusive` / `Failover` / `Key_Shared` subscription types,
  `MessageListener` dispatch on the client's listener threads, pooled messages,
  batch-index acknowledgment, the chunked-message knobs, the receiver-queue
  limits and the auto-scaled receiver-queue reporting on the consumer;
- the v4 `Reader` itself — `read` measures a V5 `CheckpointConsumer`, a
  different broker-side entity — along with a `lid:eid` start message id,
  `--receiver-queue-size` and `--use-tls`;
- the v4 transaction coordinator, which stays a live broker code path next to
  the v5 one (PIP-473 P5.4) with nothing driving it, and its acknowledgement
  round-trip latency (V5's `acknowledge` is a synchronous void, so its reported
  ack latency is a local measurement).

### Modifications

Each benchmark is split into an abstract base holding everything that is not
client-specific — the CLI options, the throughput/latency accounting, the
run() skeleton and message loop, and the reports — plus two thin subclasses
that bind the client types: the existing V5 command, and a new v4 one.

    PerformanceProducerBase    -> PerformanceProducer     / PerformanceProducerV4     (produce-v4)
    PerformanceConsumerBase    -> PerformanceConsumer     / PerformanceConsumerV4     (consume-v4)
    PerformanceReaderBase      -> PerformanceReader       / PerformanceReaderV4       (read-v4)
    PerformanceTransactionBase -> PerformanceTransaction  / PerformanceTransactionV4  (transaction-v4)

This is a split rather than a revert, so the bases keep the improvements made
since the migration — instance recorders, the 3-significant-digit histograms
and the latency clamps from apache#26466, class-based subcommand registration from
apache#26467 — and both commands share one benchmark and one set of measurements.
The v4 commands offer the same flags as their V5 counterparts (only the
V5-only `--scalable-consumer-type` and `--scalable` are not mirrored).

Each base logs through a logger named after the concrete subclass, so the
report lines keep naming the subcommand that produced them.

Where the two clients genuinely differ, the seam is explicit: the v4 consumer
and reader keep `MessageListener`/`ReaderListener` dispatch while V5 keeps its
poll threads; the v4 producer does not await a transaction's sends before
committing (V5 must, because its transactional sends are queued onto an
internal dispatch chain); only the first transaction of a V5 test thread waits
out the coordinator's asynchronous connect, so the rollover loop still counts
every failed open.

`--jsse-provider` / `--jca-provider` are also wired into the v4 client builder,
which previously read them only for the admin and V5 legs.

### Verifying this change

New unit and end-to-end tests in `pulsar-testclient` cover subcommand
registration and naming, conf-file defaults and case-insensitive enums on the
v4 commands, the shared `-st` enum mapping onto the v4 client enum, produce /
consume / read round trips through the v4 commands, the `lid:eid` start
position, and the v4-only producer knobs. `PerfToolTest` gains v4 cases that
run the commands from `bin/pulsar-perf` in a container.

…ient (#26480)

### Motivation

`pulsar-perf` was migrated to the V5 client API in #25887 and `pulsar-client` in #25917, so every
subcommand of both tools now drives the V5 SDK. Pulsar 5.0 does not deprecate ordinary
(non-scalable) topics and the v4 client remains fully supported, so it is still useful to drive the
CLI tools with the v4 client: for benchmark results comparable across broker versions (the v4
commands can also target pre-5.0 brokers, which the V5 SDK cannot talk to at all), and for testing
the v4 client and ordinary topics without the V5 SDK in the path.

The migration also left a set of options that are still accepted but no longer do what they say,
with no way to get the behaviour back — round-robin partition routing and the outstanding-message
limits on `produce`, the real subscription types and the receiver-queue knobs on `consume`, the v4
`Reader` and its `<ledgerId>:<entryId>` start position on `read`, the v4 transaction coordinator on
`transaction`, KeyValue schemas and non-durable subscriptions on `pulsar-client`, and `loadConf`
for `client.conf` keys without a dedicated CLI flag.

### Modifications

Each command is split into an abstract base holding everything that is not client-specific, plus two
thin sibling subclasses that bind the client types — the existing V5 command and a new v4 one:

```
PerformanceProducerBase    -> PerformanceProducer    / PerformanceProducerV4    (produce-v4)
PerformanceConsumerBase    -> PerformanceConsumer    / PerformanceConsumerV4    (consume-v4)
PerformanceReaderBase      -> PerformanceReader      / PerformanceReaderV4      (read-v4)
PerformanceTransactionBase -> PerformanceTransaction / PerformanceTransactionV4 (transaction-v4)

AbstractCmdProduce         -> CmdProduce             / CmdProduceV4             (produce-v4)
AbstractCmdConsumeCommand  -> CmdConsume             / CmdConsumeV4             (consume-v4)
AbstractCmdReadCommand     -> CmdRead                / CmdReadV4                (read-v4)
```

`PulsarClientTool` builds a second, lazily-supplied v4 `ClientBuilder` for the `*-v4` commands; it
keeps `loadConf` and accepts `http://` service URLs. `pulsar-shell` picks the new `pulsar-client`
commands up for free, and both tools' `gen-doc` / `generate_documentation` render them.

New subcommands only. The V5 commands keep their behaviour apart from a few deliberate fixes that
the split surfaced (the `ProducerSocket` send/ack ordering and its `close()` null guard, the
transaction receive-failure path), plus some added "use the `-v4` command" pointers on existing
warnings — all listed in the PR description.

### Verifying this change

Covered by `PulsarPerfTestToolTest`, `PerformanceV4CommandsTest`, `PerformanceTransactionV4Test`,
`CmdV4CommandsTest`, `PulsarClientToolTest` (including the three KeyValue cases disabled by #25917,
now re-enabled against `produce-v4`), and new `produce-v4` / `consume-v4` / `read-v4` cases in the
`PerfToolTest` integration test.

…ient (apache#26480)

### Motivation

`pulsar-perf` was migrated to the V5 client API in apache#25887 and `pulsar-client` in apache#25917, so every
subcommand of both tools now drives the V5 SDK. Pulsar 5.0 does not deprecate ordinary
(non-scalable) topics and the v4 client remains fully supported, so it is still useful to drive the
CLI tools with the v4 client: for benchmark results comparable across broker versions (the v4
commands can also target pre-5.0 brokers, which the V5 SDK cannot talk to at all), and for testing
the v4 client and ordinary topics without the V5 SDK in the path.

The migration also left a set of options that are still accepted but no longer do what they say,
with no way to get the behaviour back — round-robin partition routing and the outstanding-message
limits on `produce`, the real subscription types and the receiver-queue knobs on `consume`, the v4
`Reader` and its `<ledgerId>:<entryId>` start position on `read`, the v4 transaction coordinator on
`transaction`, KeyValue schemas and non-durable subscriptions on `pulsar-client`, and `loadConf`
for `client.conf` keys without a dedicated CLI flag.

### Modifications

Each command is split into an abstract base holding everything that is not client-specific, plus two
thin sibling subclasses that bind the client types — the existing V5 command and a new v4 one:

```
PerformanceProducerBase    -> PerformanceProducer    / PerformanceProducerV4    (produce-v4)
PerformanceConsumerBase    -> PerformanceConsumer    / PerformanceConsumerV4    (consume-v4)
PerformanceReaderBase      -> PerformanceReader      / PerformanceReaderV4      (read-v4)
PerformanceTransactionBase -> PerformanceTransaction / PerformanceTransactionV4 (transaction-v4)

AbstractCmdProduce         -> CmdProduce             / CmdProduceV4             (produce-v4)
AbstractCmdConsumeCommand  -> CmdConsume             / CmdConsumeV4             (consume-v4)
AbstractCmdReadCommand     -> CmdRead                / CmdReadV4                (read-v4)
```

`PulsarClientTool` builds a second, lazily-supplied v4 `ClientBuilder` for the `*-v4` commands; it
keeps `loadConf` and accepts `http://` service URLs. `pulsar-shell` picks the new `pulsar-client`
commands up for free, and both tools' `gen-doc` / `generate_documentation` render them.

New subcommands only. The V5 commands keep their behaviour apart from a few deliberate fixes that
the split surfaced (the `ProducerSocket` send/ack ordering and its `close()` null guard, the
transaction receive-failure path), plus some added "use the `-v4` command" pointers on existing
warnings — all listed in the PR description.

### Verifying this change

Covered by `PulsarPerfTestToolTest`, `PerformanceV4CommandsTest`, `PerformanceTransactionV4Test`,
`CmdV4CommandsTest`, `PulsarClientToolTest` (including the three KeyValue cases disabled by apache#25917,
now re-enabled against `produce-v4`), and new `produce-v4` / `consume-v4` / `read-v4` cases in the
`PerfToolTest` integration test.