155616: rangefeed: add assertion that OnError is called on disconnected registration r=stevendanna a=stevendanna

Epic: none
Release note: None

155797: *: replace some usages of global rand r=yuzefovich a=yuzefovich

**sem/builtins: use RNG from eval context for 'st_generatepoints'**

***: replace some usages of global rand**

When we use `rand.*` methods like `math/rand.Intn`, under the hood we hit
the global rand source, which is protected by a mutex, so we could be subject
to contention on that lock. This commit updates some of such usages in
favor of object-specific rand source to avoid that. Note that allocating
a separate rand source is not free (the allocation itself is about 5KiB
in size), so we modify spots where the lifecycle matches that of the
server or when the affected code is heavy already / not on the hot path
(also when it's clear that the access is from within a single
goroutine).

Epic: None
Release note: None

155861: kvserver: deflake TestPromoteNonVoterInAddVoter r=arulajmani a=arulajmani

This test could previously fail because a lease transfer could race with a split. Without the split, the effects of the span config (that the test asserts on) will not apply. We sidestep this problem by removing the need of a split entirely -- by tuning some cluster settings to ensure that every table is on its own range to begin with.

H/t to `@pav-kv` for the analysis on this one.

Closes #155828 
Closes #155747 
Closes #155316 
Closes #154773 
Closes #134383

Release note: None

Co-authored-by: Steven Danna <danna@cockroachlabs.com>
Co-authored-by: Yahor Yuzefovich <yahor@cockroachlabs.com>
Co-authored-by: Arul Ajmani <arulajmani@gmail.com>

This reverts commit a884f8f (cockroachdb#155861).

As far as I understand, the cluster settings in this commit had the
effect of making sure that the span config for the table in the test
was exactly `[/Table/N,/Table/(N+1))`, i.e. that it wouldn't merge
with adjacent configs. But in a recent flake we see that the real
problem is that the range containing our table sometimes extends
past the span config (in a recent example, it reached the end of
the keyspace and wasn't split down in time for the test to pass).

Since commits in this PR ensure that the splitting happens proactively, it
should not matter whether span configs are coalesced or not, and we back out
that attempt at a fix as it's unclear what positive effect it may have.

@arulajmani: I'm probably missing something here. Happy to update
the description if so.

This reverts commit a884f8f (cockroachdb#155861).

As far as I understand, the cluster settings in this commit had the
effect of making sure that the span config for the table in the test
was exactly `[/Table/N,/Table/(N+1))`, i.e. that it wouldn't merge
with adjacent configs. But in a recent flake we see that the real
problem is that the range containing our table sometimes extends
past the span config (in a recent example, it reached the end of
the keyspace and wasn't split down in time for the test to pass).

Since commits in this PR ensure that the splitting happens proactively, it
should not matter whether span configs are coalesced or not, and we back out
that attempt at a fix as it's unclear what positive effect it may have.

@arulajmani: I'm probably missing something here. Happy to update
the description if so.

This reverts commit a884f8f (cockroachdb#155861).

As far as I understand, the cluster settings in this commit had the
effect of making sure that the span config for the table in the test
was exactly `[/Table/N,/Table/(N+1))`, i.e. that it wouldn't merge
with adjacent configs. But in a recent flake we see that the real
problem is that the range containing our table sometimes extends
past the span config (in a recent example, it reached the end of
the keyspace and wasn't split down in time for the test to pass).

Since commits in this PR ensure that the splitting happens proactively, it
should not matter whether span configs are coalesced or not, and we back out
that attempt at a fix as it's unclear what positive effect it may have.

@arulajmani: I'm probably missing something here. Happy to update
the description if so.

This reverts commit a884f8f (cockroachdb#155861).

As far as I understand, the cluster settings in this commit had the
effect of making sure that the span config for the table in the test
was exactly `[/Table/N,/Table/(N+1))`, i.e. that it wouldn't merge
with adjacent configs. But in a recent flake we see that the real
problem is that the range containing our table sometimes extends
past the span config (in a recent example, it reached the end of
the keyspace and wasn't split down in time for the test to pass).

Since commits in this PR ensure that the splitting happens proactively, it
should not matter whether span configs are coalesced or not, and we back out
that attempt at a fix as it's unclear what positive effect it may have.

@arulajmani: I'm probably missing something here. Happy to update
the description if so.

This reverts commit a884f8f (cockroachdb#155861).

As far as I understand, the cluster settings in this commit had the
effect of making sure that the span config for the table in the test
was exactly `[/Table/N,/Table/(N+1))`, i.e. that it wouldn't merge
with adjacent configs. But in a recent flake we see that the real
problem is that the range containing our table sometimes extends
past the span config (in a recent example, it reached the end of
the keyspace and wasn't split down in time for the test to pass).

Since commits in this PR ensure that the splitting happens proactively, it
should not matter whether span configs are coalesced or not, and we back out
that attempt at a fix as it's unclear what positive effect it may have.

@arulajmani: I'm probably missing something here. Happy to update
the description if so.

This reverts commit a884f8f (cockroachdb#155861).

As far as I understand, the cluster settings in this commit had the
effect of making sure that the span config for the table in the test
was exactly `[/Table/N,/Table/(N+1))`, i.e. that it wouldn't merge
with adjacent configs. But in a recent flake we see that the real
problem is that the range containing our table sometimes extends
past the span config (in a recent example, it reached the end of
the keyspace and wasn't split down in time for the test to pass).

Since commits in this PR ensure that the splitting happens proactively, it
should not matter whether span configs are coalesced or not, and we back out
that attempt at a fix as it's unclear what positive effect it may have.

@arulajmani: I'm probably missing something here. Happy to update
the description if so.