Perf coverage baseline: X7 + X8 macros, cold-start (issue #557), latency curve, bandwidth

[Tagar]

Merge this PR first. It establishes the baseline measurements (X7 recv + X8 send macros in CodSpeed, plus a comprehensive local test suite) that the open optimization PRs validate against.

Merge order

1. Perf coverage baseline: X7 + X8 macros, cold-start (issue #557), latency curve, bandwidth #7 (this) — first. Adds X7/X8 macros + coverage tests. CodSpeed dashboard now tracks bytes recv + bytes send at 16K.
2. perf: decode_bytearray (closes #570) + hot-path smart_decode shortcuts (credit @markjm #575) #5 (decode_bytearray fix). Recv side gets ~7.5× faster in microbench; X7-16k drops on the CodSpeed dashboard.
3. perf: disable Nagle's algorithm on py4j socket connections (closes #516) #6 (Nagle disable, closes Performance Issue due to TCP Nagle's Algorithm write,write,read Situation py4j/py4j#516). On Linux runners, X7-16k and X8-16k drop dramatically (issue Performance Issue due to TCP Nagle's Algorithm write,write,read Situation py4j/py4j#516's 4.4 s/100 calls reproducer is exactly the X7-16k pattern).

CodSpeed scenarios (perf framework)

• X7 — bytes round-trip RECV at 1k / 16k / 256k. Each call round-trips ByteBuffer.array() over the wire, routes through OUTPUT_CONVERTER[BYTES_TYPE] → decode_bytearray. Without X7 the decode_bytearray path is a measurement blind spot.
• X8 — bytes SEND at 1k / 16k / 256k. Encode + Python→Java byte[] via BAOS.write(byte[], int, int). Exercises encode_bytearray and the send-side BufferedWriter overflow boundary.

Both X7-16k and X8-16k are registered for CodSpeed CI.

perf_coverage_test.py — run with pytest -v -s

ColdStartLatencyTest (issue py4j#557)

Three measurements, progressively excluding more of the cold path so a regression can be localized:

• test_full_cold_start — fresh java subprocess + listening-socket wait + py4j handshake + first call. JVM init dominates (matches issue Slow first call to Java from Python py4j/py4j#557's reported ~3 s window). Caps <30 s.
• test_py4j_handshake_under_500ms — JVM already listening; only JavaGateway() + first call timed. Isolates py4j's contribution (~1 ms locally).
• test_first_vs_warm_call_ratio — first call vs warm median. Catches regressions in protocol-cache fill.

StringArgLatencyCurveTest

Per-call latency at string-argument sizes 16 / 256 / 4K / 16K / 64K bytes. Fills the gap between M2b (~5 B arg) and X7-class large payloads. Surfaces the Nagle knee around the BufferedWriter buffer boundary (~8 K) on Linux.

BandwidthSummaryTest

MB/s at 1K / 16K / 256K for both directions (recv via ByteBuffer.array, send via BAOS.write). Asserts >0.1 MB/s floor.

Local sample output (macOS loopback)

[full-cold-start] subprocess.Popen -> first call: 0.31 s
[py4j-handshake-only] gateway+first-call: 1.4 ms
[first-vs-warm] first: 196us  warm-median: 108.4us  ratio: 1.8x
[string-arg latency curve]
       16 B arg:    361.2 us/call
      256 B arg:    270.6 us/call
     4096 B arg:    339.6 us/call
    16384 B arg:    387.6 us/call
    65536 B arg:    462.9 us/call
[bandwidth summary]
       size    recv MB/s    send MB/s
      1024B          7.1          6.8
     16384B         60.3         79.3
    262144B         94.1        244.7

macOS loopback shows no Nagle penalty (Linux CodSpeed runners will); send is ~2.5× faster than recv at 256K because recv pays the base64-decode + list-comprehension cost in decode_bytearray that PR #5 fixes.

Co-authored-by: Isaac