ALTER TABLE ... SPLIT AT now requires merge queue to be disabled

[benesch]

cockroachdb/cockroach#28961 (which will soon be backported) has the following release note:

Release note (sql change): ALTER TABLE ... SPLIT AT now produces an
error if executed while the merge queue is enabled, as the merge queue
is likely to immediately discard any splits created by the statement.

More details from the issue:

The above has implications for the documentation of ALTER TABLE ... SPLIT AT. Users are now prevented from splitting a table unless they disable the merge queue with SET CLUSTER SETTING kv.range_merge.queue_enabled = false. This is so that users are not confused when their manual splits are immediately merged away by the merge queue. (We're planning to come up with a more user friendly solution to this in v2.2.) They can turn the merge queue back on once they've ensured that their newly split ranges exceed the minimum range size (1MB), guaranteeing that they won't be merged away.

Let me know if you need any more details!

/cc @jseldess

[rmloveland]

@awoods187 went with P-1 on this one since (IIRC) range merges will be on by default in 2.2, which means this docs issue will need to be addressed in that timeframe. Do you agree?

[jseldess]

Related, from @bdarnell:

we should update our guidance around manual splits. now you should either A) do nothing and trust in load-based spliting or B) disable the merge queue, split manually, and re-enable the merge queue after load/capacity has ramped up and the manual splits are no longer necessary

[sploiselle]

@awoods187 Who would be the best engineering resource for this?

[bdarnell]

Probably me.

[rmloveland]

Closing since AFAICT this was fixed by @ericharmeling in #5642