[fix][cli] pulsar-perf: register subcommand classes with picocli instead of instances - #26467

…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.

…ead of instances (#26467)

(cherry picked from commit f41e620)

…ead of instances (#26467)

(cherry picked from commit f41e620)

…ead of instances (apache#26467)