[fix][txn] Allow producer enable send timeout in transaction - #16519

(cherry picked from commit bbf2a47)

(cherry picked from commit bbf2a47)

…16519)

(cherry picked from commit bbf2a47)
(cherry picked from commit 5f8a8f7)

…MessageTimeout (only release branches) (#16570)

### Motivation

`TransactionEndToEndTest#testSendTxnMessageTimeout` fails on releases branch after #16519 has been cherry-picked. 

```
java.lang.AssertionError: expected [true] but found [false]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertTrue(Assert.java:45)
	at org.testng.Assert.assertTrue(Assert.java:55)
	at org.apache.pulsar.client.impl.TransactionEndToEndTest.testSendTxnMessageTimeout(TransactionEndToEndTest.java:1099)
```

The reason is that the mock setup must be slightly different since the `ProducerImpl` is not exactly the same between master and branch-2.10.

…16519)

…MessageTimeout (only release branches) (#16570)

### Motivation

`TransactionEndToEndTest#testSendTxnMessageTimeout` fails on releases branch after #16519 has been cherry-picked. 

```
java.lang.AssertionError: expected [true] but found [false]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertTrue(Assert.java:45)
	at org.testng.Assert.assertTrue(Assert.java:55)
	at org.apache.pulsar.client.impl.TransactionEndToEndTest.testSendTxnMessageTimeout(TransactionEndToEndTest.java:1099)
```

The reason is that the mock setup must be slightly different since the `ProducerImpl` is not exactly the same between master and branch-2.10.

…MessageTimeout (only release branches) (apache#16570)

### Motivation

`TransactionEndToEndTest#testSendTxnMessageTimeout` fails on releases branch after apache#16519 has been cherry-picked.

```
java.lang.AssertionError: expected [true] but found [false]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertTrue(Assert.java:45)
	at org.testng.Assert.assertTrue(Assert.java:55)
	at org.apache.pulsar.client.impl.TransactionEndToEndTest.testSendTxnMessageTimeout(TransactionEndToEndTest.java:1099)
```

The reason is that the mock setup must be slightly different since the `ProducerImpl` is not exactly the same between master and branch-2.10.

(cherry picked from commit c83bede)

…MessageTimeout (only release branches) (apache#16570)

### Motivation

`TransactionEndToEndTest#testSendTxnMessageTimeout` fails on releases branch after apache#16519 has been cherry-picked.

```
java.lang.AssertionError: expected [true] but found [false]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertTrue(Assert.java:45)
	at org.testng.Assert.assertTrue(Assert.java:55)
	at org.apache.pulsar.client.impl.TransactionEndToEndTest.testSendTxnMessageTimeout(TransactionEndToEndTest.java:1099)
```

The reason is that the mock setup must be slightly different since the `ProducerImpl` is not exactly the same between master and branch-2.10.

(cherry picked from commit c83bede)

…ands

Follow-up to the review on apache#26480, pulsar-perf half.

- `transaction-v4` had no functional coverage: every existing reference was
  metadata-only, so the transaction binding itself was unpinned. Adds
  `PerformanceTransactionV4Test` with a commit run and an `-abort` run against
  plain `persistent://` topics. The commit run asserts both halves are durable
  (produced messages visible, consume backlog down by one per transaction); the
  abort run asserts neither is (nothing visible, backlog unchanged, and all ten
  messages redeliverable on the tool's own subscription, which is what separates
  a real abort from a transaction that was merely never ended). Mutation checked:
  making `sendMessage` or `acknowledgeAsync` ignore the transaction, dropping the
  acknowledgement entirely, or making `abortTransaction` a no-op each fail it.

- `PerformanceConsumerBase` had dropped the `consumerType` attribute from the
  per-topic "Adding consumers" line, which the pre-split `PerformanceConsumer`
  logged. Restores it through a `consumerTypeForLog()` hook: the base reports
  the shared `--subscription-type`, `PerformanceConsumer` overrides it with
  `scalableConsumerType`, so the V5 line matches the pre-split output again.

- `PerformanceTransactionBase` interrupted `Thread.currentThread()` from its
  failure callbacks. That is the worker thread for a V5 ack, whose future is
  already complete when returned, but a client-internal thread for a v4 ack and
  for the send and end-transaction futures on both clients. All three callbacks
  now capture the worker thread, which is the thread `runWorker` invokes them on.

- `transaction-v4`'s and `produce-v4`'s `sendTimeout(0)` was annotated "a send
  timeout and a transaction are mutually exclusive on the v4 client". That guard
  was removed in apache#16519; the setting is still right because a send timeout fails
  the send on its own schedule and takes the transaction with it, so the comments
  now say that instead.

- `PerformanceV4CommandsTest`: the backlog assertion now waits with Awaitility
  (the exit latch is released before the client close that flushes the acks, and
  the 30s join is unchecked), and the delivery-time assertions also pin each
  message's payload so a future reordering fails legibly.

- The `LATENCY_HISTOGRAM_SIGNIFICANT_DIGITS` rationale still described the
  static recorders that apache#26466 replaced with instance fields in the same commit
  that added the comment. Rewords both copies, with the figure re-measured on
  HdrHistogram 2.2.2: 16.00 MB (1h in micros) and 14.00 MB (10d in millis) at
  5 digits, not the pre-apache#26466 ranges' 11-22 MB.