Always issue HELLO when the server should understand it, not just for RESP3 (#3175)

* Always issue HELLO when the server should understand it, not just for RESP3

Fixes #2968 (remaining concern).

When INFO is unavailable, discovery fell back to `SET {guid} replica-read-only PX 1 NX`
to detect a read-only replica. That probe writes a random, unprefixable key, so it can
never be allow-listed by an ACL key pattern - which is exactly the situation that makes
INFO unavailable in the first place (INFO and CONFIG are both @dangerous). HELLO's reply
carries "role", needs no key, and is in the @connection category.

So: issue HELLO whenever it is available and the assumed server version is 6.0+, and skip
the key-based probe when HELLO is going to tell us (or has already told us) the role. Two
independent opt-outs remain: `$hello=` in the command map, and a sub-6.0 `defaultVersion`.
As a bonus, RESP2 connections now learn the server version, mode and connection id from
the handshake as well.

The RESP2 HELLO is deliberately not the same message as the RESP3 one:

- `HELLO 3` stays first-in-pipeline and carries the credentials, as it must for RESP3
  negotiation to happen at all on a secured server.
- `HELLO 2` is a bare HELLO issued *after* AUTH, on the interactive connection only. It
  isn't negotiating anything, and folding credentials in would change how credential
  failures surface (there is a pre-existing difference in behaviour between AUTH failing
  on its own and AUTH failing inside HELLO; that is a separate bug, not one to inherit
  here).

Also excludes HELLO from the twemproxy and envoyproxy command maps, and verifies against
both proxies locally:

- twemproxy 0.5.0 (the newest release) *closes the connection* on an unsupported command,
  so HELLO is fatal. Since v3 raised the assumed default version to 6.0, RESP3 - and
  therefore HELLO - became the default, and a default-configured twemproxy connection
  never became usable at all. That is a v3 regression against v2, where the assumed
  version of 3.0 meant no HELLO was ever sent.
- envoy up to ~1.31 answers "unsupported command"; 1.39 instead proxies HELLO to an
  arbitrary backend node, so the version/role/mode in the reply describe some other
  server. Taking that at face value would flip a proxy endpoint into cluster mode or mark
  it as a replica, so HELLO's mode/role are now only applied to server types that support
  auto-configure - proxies are excluded even if a hand-rolled command map re-enables the
  command.

Bumps the test-topology envoy pin from v1.31 to v1.39 (8 minors stale, and the two
versions behave differently here).

Tests use a recording in-process server to pin exactly which commands the handshake
issues: HELLO at the right protocol level, absent when disabled either way, and the
replica probe present only when HELLO cannot tell us the role. The Resp3HandshakeTests
matrix no longer skips RESP2 clients (they issue HELLO now too), and asserts the
negotiated protocol.

* Drop the discovery-HELLO logger message

EventId 110 is in use in another in-progress PR, and this doesn't warrant a
logger message of its own - the handshake HELLO is already visible in the
detail/parse logs.