Revert "rangefeed: unconditionally use rangefeed scheduler"

[erikgrinaker]

This reverts 3/4 commits from #114410, only leaving 1dbdbe9 which enabled the scheduler by default.

There was significant code drift in tests, but I think I've been able to address the conflicts.

This revert does not integrate with the changes from #120347, so the legacy rangefeed processor will not use the improved memory accounting. We still shouldn't leak budget allocations, since the processor implementations are entirely independent, but it's worth having a second look to make sure the registry (which is used by both processors) don't make assumptions about this.

Touches #121054.
Epic: none.
Release note: the following release note from #114410 should be reverted/ignored: "the setting kv.rangefeed.scheduler.enabled has been removed, as the rangefeed scheduler is now unconditionally enabled".

[blathers-crl]

Your pull request contains more than 1000 changes. It is strongly encouraged to split big PRs into smaller chunks.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[cockroach-teamcity]

This change is 

[erikgrinaker]

I've run a few roachtests to verify, seems to work fine. I think this should be good to go.

it's worth having a second look to make sure the registry (which is used by both processors) don't make assumptions about this

SharedBudgetAllocation.Use() and Release() handle nil allocations just fine, so it's ok for the legacy processor to not attach allocations to all events.

[wenyihu6]

re: memory accounting part, legacy and scheduled processor seem to handle everything the same way, except for my recent changes (which is just an improvement, no memory leaks without it), so it looks fine.

I will defer the stamp to those who reviewed the original PRs though.

[rharding6373]

Why were the reverts in store.go and testing_knobs.go no longer needed?

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @DarrylWong, @erikgrinaker, @nvanbenschoten, @renatolabs, and @wenyihu6)

---

pkg/kv/kvclient/rangefeed/rangefeed_external_test.go line 69 at r4 (raw file):

func (t feedProcessorType) String() string {
	return fmt.Sprintf("single/scheduler=%t", t.useScheduler)

Should this be mux instead of single?

[erikgrinaker]

It didn't seem useful to revert those changes -- I think we want the scheduler to be responsive to testing knobs regardless.

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @DarrylWong, @nvanbenschoten, @renatolabs, @rharding6373, and @wenyihu6)

---

pkg/kv/kvclient/rangefeed/rangefeed_external_test.go line 69 at r4 (raw file):

Previously, rharding6373 (Rachael Harding) wrote…

Should this be mux instead of single?

It should, good catch -- thanks!

[erikgrinaker]

I'm going to optimistically bors this to get it in before the branch cut, as I only changed a string since the last CI run.

bors r+

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)
• check_generated_code
• docker_image_amd64
• examples_orms
• linux_amd64_build
• linux_amd64_fips_build
• linux_arm64_build
• macos_amd64_build
• macos_arm64_build
• windows_build