Skip the client response-time Observation when no tracing is configured

[samueldlightfoot]

Change

With .metrics(true) and no tracing configured, the client runs a full Micrometer Observation per request to
record one timer. Nothing consumes it. It is 43.4% of the allocation that enabling metrics adds to the client
event loop.

When the ObservationRegistry is the untouched built-in default, startWrite now skips the Observation and
recordRead records the response.time Timer directly. Same meter, name, tags and value.

Deciding "untouched" needs Reactor Netty to own the registry: ObservationConfig's accessors are
package-private, and the documented tracing setup mutates the default registry in place rather than replacing
it, so registry identity alone can't answer it. DEFAULT_OBSERVATION_REGISTRY tracks whether any handler,
predicate, filter or convention was registered after Reactor Netty installed its own. Registering any of them,
or assigning OBSERVATION_REGISTRY, re-engages the full lifecycle.

The response-time meter name is also precomputed on the recorder rather than rebuilt twice per request.

Behaviour

Two visible deltas, both intended:

• With the untouched default registry there is no longer an Observation on the channel context, so code
  reading OBSERVATION_KEY off a client channel finds nothing. Registering any handler, predicate, filter
  or convention — or assigning OBSERVATION_REGISTRY — restores it.
• The REMOTE_ADDRESS tag on response.time now uses formatSocketAddress, like every other client meter,
  instead of netPeerName + ":" + netPeerPort. For an InetSocketAddress the two are identical. For other
  remotes — a domain socket, say — the tag loses the trailing : the old form left when the port was empty.
  That is a meter-identity change for those users. The NET_PEER_NAME and NET_PEER_PORT high-cardinality
  tags are unchanged.

Benchmarks

Rig: H2C loopback, 32 threads, JDK 17, 180 s after a 30 s warmup, SimpleMeterRegistry on the global
composite, metrics on in both arms, back-to-back in one session. Allocation sampled at a fixed --alloc 512k
interval.

Benchmark	Metric	Before	After	Δ
Rig A/B, full client loop	Client-loop allocation	102,193 samples	92,270 samples	−9.7%
Rig A/B, full client loop	Throughput	94,923 req/s	97,671 / 98,719 req/s	+3–4%

[samueldlightfoot]

@violetagg keen for your thoughts on this. It could be a big win out of the box for those wanting metrics with no use for observations.

[violetagg]

I'm ok with that, but I don't feel like introducing it to the 1.3.x version. It should go to the 1.4.x version (currently the main branch). Wdyt?
I won't be able to review it for 1.4.0-M1, so it will most likely be for 1.4.0-M2.

[samueldlightfoot]

I'm ok with that, but I don't feel like introducing it to the 1.3.x version. It should go to the 1.4.x version (currently the main branch). Wdyt? I won't be able to review it for 1.4.0-M1, so it will most likely be for 1.4.0-M2.

SGTM - no rush!