Prior to this patch, an implementation of the `Authorizer` interface
was called "Noop". Unfortunately, "no-op" does not tell the reader
clearly what an *authorization policy* does. What does it allow? What
does it reject?

This patch clarifies that situation by renaming it to
"AllowEverythingAuthorizer".

Additionally, the RPC context for tenant servers was configured
with this authorizer implementation, which is conceptually confusing:
it would conceptually allow RPC clients to solicit KV operations from
it. Instead, this patch introduces a new "AllowNothingAuthorizer" for
that case.

(Note: this is purely conceptual since the RPC service for tenant
server does not, in fact, offer the roachpb.Internal service.)

Release note: None

Prior to this patch, `NewStore()` was tolerant to a missing authorizer
and would synthetize a "allow everything" authorizer in that case.

This is dangerous, because it means any programming error in the
caller where someone forgets to configure the authorizer, would result
in no rate limiting, without any indication something is amiss.

This commit rectifies the situation by requiring an authorizer to be
configured in all cases.

Release note: None

We want to ensure all KV method types have an entry in the map. This
commit adds a test for it, and adds the missing entry for `WriteBatch`
that was detected by the test.

Release note: None

Prior to this patch, there was a "authorizer enabled" cluster setting
with just two values on/off.

When off, it would let through all requests.

This was inadequate because for CC Serverless, we want an escape hatch
that disables capability checks, but still disallows sensitive
requests -- i.e. we want a way to restore the pre-v23.1 behavior.

This change achieves this by replacing the previous setting with a new
setting `server.secondary_tenants.authorizer.mode` with 3 values:

- `on`: use capability checks.
- `allow-all`: allow all operations. This can be used e.g. as
  a escape hatch when lifting a single-tenant application into
  multi-tenancy.
- `v222`: restore the pre-v23.1 behavior. In this mode, non-privileged
  operations are allowed for all tenants, and privileged operations are
  only allowed for the system tenant.

Release note: None

If the cluster version hasn't been upgraded to when capabilities were
introduced, it's better not to start looking at capabilities just yet;
because otherwise error messages would be confusing.

Release note: None

Prior to this patch, we were repeating the following cascade of checks
in each authorizer method:

1. check the cluster setting
2. check whether the reader is bound already
3. check whether the reader has data for the tenant already

Repeating all these checks every time is error prone. Instead, this
change groups them under `getMode`.

Release note: None

Release note: None