61439: sql: reference sequences used in views by their IDs r=ajwerner a=the-ericwang35

Followup to #59864, fixes #61205.
Previously, a change was introduced to store sequences
used in DEFAULT expressions to be referenced by their
IDs instead of their names, to allow sequence renaming.
In this patch, we want to do something similar by
rewriting sequence references in views to be
referenced by their IDs. This allows sequences
used in views to be renamed.

Another thing this PR does is change the output of sequences
to look like `'s'::REGCLASS` rather than `'s':::STRING::REGCLASS`,
since we're no longer type checking them (since it's unnecessary).

Release note (sql change): reference sequences used in views
by their IDs to allow these sequences to be renamed.

61682: kvserver: teach replicateQueue to replace dead/decommisioning non-voters r=aayushshah15 a=aayushshah15

The PR is very similar to #59403.

Previously, non-voters on dead or decommissioning nodes would not get
removed or replaced. This commit fixes this behaviour.

Resolves #61626

Release justification: fixes limitation where dead/decommissioning
non-voters would not be removed or replaced
Release note: None


61967: kvserver: stop spuriously refusing non-voters in replicateQueue.shouldQueue() r=aayushshah15 a=aayushshah15

Before this commit, the `replicateQueue` would refuse to queue up a
replica into the queue (in its `shouldQueue` method) for the rebalancing
case unless it could verify that a voting replica needed to be
rebalanced. This was an unfortunate oversight since it meant that unless
there was a voting replica to be rebalanced, non-voters would not get
rebalanced by the queue.

This commit fixes this bug.

Noticed while debugging a flakey test for #61682

Release justification: bug fix
Release note: None

62009: build: perform `bazel clean --expunge` on `make clean` r=rickystewart a=rickystewart

Release note: None

62186: sql: ensure user has correct privileges when adding/removing regions r=richardjcai a=arulajmani

Previously we did not account for privileges on database objects when
adding the default locality config on first region add or removing the
locality config on last region drop properly. In particular, we weren't
adding/removing the locality config on any descriptor that wasn't
visible to the user. This is bad because our validation logic expects
only and all objects in multi-region databases to have a valid locality
config. This means future accesses to such descriptors would fail
validation.

The root of this problem was the API choice here, `ForEachTableDesc`,
which filters out invisible descriptors. This patch instead switches
to using `forEachTableInMultiRegionDatabase`. While here, instead of
issuing separate requests for every table, I refactored this thing to
issue a single batch request instead.

Now that we view all the descriptors inside the database, unfiltered,
we perform privilege checks on them before proceeding with the add/drop
operation. In particular, the semantics are:
- admin users are allowed to add/drop regions as they wish.
- non admin-users require the CREATE privilege or must have ownership
on all the objects inside the database.

Closes #61003

Release note (sql change): `ALTER DATABASE .. SET PRIMARY REGION` now
requires both CREATE and ZONECONFIG privilege on all  objects inside
the database when adding the first region to the database. Same for
dropping the last region using `ALTER DATABASE ... DROP REGION`.

Co-authored-by: Eric Wang <ericw@cockroachlabs.com>
Co-authored-by: Aayush Shah <aayush.shah15@gmail.com>
Co-authored-by: Ricky Stewart <ricky@cockroachlabs.com>
Co-authored-by: arulajmani <arulajmani@gmail.com>