V3 Tracking Branch - #3083

…e command (#3237)

* IServer.Execute supplies the default database rather than refusing the command

server.Execute("DBSIZE") - and KEYS, SCAN, RANDOMKEY, OBJECT, DEBUG, FLUSHDB,
EVAL - threw "A target database is required". Message.RequiresDatabase answers
true for anything not on its exclusion list, and IServer.Execute passes -1,
having no database to offer.

This is a v3 regression. Ad-hoc commands used to travel as RedisCommand.UNKNOWN,
which the Message constructor deliberately exempts from the check, so it never
applied to this path at all; #3083 began recognising them so CommandMap aliasing
would work, which brought the assertion with it. The sibling direction from
IDatabase was given an allowance at the same time - RemoveDbIfNotRequired strips
a database that is not needed, with a comment noting we should not start
complaining about what was historically accepted. IServer got no such allowance.

Resolve the default database instead of refusing, but only where the command
actually requires one, so nothing else changes: commands on the exclusion list
and commands we do not recognise still travel with no database and leave the
connection's selection alone.

Uses multiplexer.ApplyDefaultDatabase, which is what the database-taking
Execute overload already does for a null database, and what DatabaseSize,
FlushDatabase and friends already do. That makes server.Execute("DBSIZE") agree
with server.DatabaseSize() - before this they were the same command reaching
different databases.

Note this is deliberately *not* a return to the v2 behaviour. Sending with no
SELECT meant the command ran against whichever database that physical connection
had last selected, so the answer depended on unrelated earlier calls; measured
against a live server, a connection that had touched database 5 and then 9
reported db=5 then db=9 for commands that named no database at all. Restoring
that exactly would mean restoring results that are silently wrong for anyone
using more than one database.

The tests cover all three routes through RemoveDbIfNotRequired, and assert which
database the connection ends up on rather than comparing key counts - the server
is shared with other tests, so counts move and two readings of one prove nothing.
CLIENT INFO works as the oracle precisely because CLIENT is on the exclusion
list and so does not itself move the selection.

* Pin the no-database half, and say which database Execute uses

Review follow-ups on the tests, plus the documentation gap.

ExclusionListCommandsStillSendNoSelect only called CLIENT INFO twice, so it
proved nothing the oracle helper did not already assume, and nothing covered
the unrecognised-command route at all. It now runs PING (recognised, on the
exclusion list) and ACL WHOAMI (not recognised, so the assertion never applied)
between the readings, and is renamed for what it actually asserts.

That turns out to be the half worth pinning. Replacing DatabaseForAdHoc with
the simpler "always pass the default and let RemoveDbIfNotRequired strip it"
fails exactly there, and nowhere else: that method only strips for recognised
commands, so ACL keeps the database and starts emitting SELECT. The test was
silent about this before. The original bug still fails the other eight.

Also: the missing Assert.NotEqual(0, otherDb) guard, without which "still on
otherDb" would hold whether or not a SELECT happened; a skip for DEBUG via the
existing AssertDebugCommandEnabledAsync, since Redis 7 disables it by default
and only this repo's own config turns it on; version requirements for ACL
(6.0), FUNCTION (7.0) and CLIENT INFO (6.2, the oracle), matching how the rest
of the suite gates; and a comment saying Assert.NotNull is deliberately weak -
the assertion is that it does not throw, and reading the reply would only
couple the test to server versions.

The IServer.Execute docs did not mention databases at all, and the overload
taking no database claimed the command "is assumed to be not database-specific"
- which was the behaviour being fixed. Both now say a command that requires a
database uses the configured default, and point at the database-taking overload
for anything else.

* Drop a version guard that can never be false

The ACL step in CommandsNeedingNoDatabaseLeaveTheSelectionAlone was guarded on
6.0, but the test already requires 6.2 for CLIENT INFO, so the branch is always
taken. A guard that cannot fail is worse than none: it reads as though the step
is optional, and nothing would notice if it stopped running. Left a note saying
which requirement covers it, so it is obvious what to restore if the 6.2 one
ever goes.