fix serialize_worker_startup=false mode

[rnewson]

Overview

serialize_worker_startup = true|false is a new toggle, defaulting to true, introduced in #5371.

When set to false CouchDB should work as before, starting all workers in parallel. However, the work in commit "consider a conflict a final decision" only works correctly in true mode.

This PR changes all relevant functions to their original behaviour in false mode.

Getting the value of the setting passed to all the right places is the bulk of the code, and is quite ugly.

Testing recommendations

true mode is covered by tests, false mode ... not so much. thoughts welcome.

Related Issues or Pull Requests

#5371

Checklist

• This is my own work, I did not use AI, LLM's or similar technology
• Code is written and works correctly
• Changes are covered by tests
• Any new configurable parameters are documented in rel/overlay/etc/default.ini
• Documentation changes were made in the src/docs folder
• Documentation changes were backported (separated PR) to affected branches

[rnewson]

If accepted, this PR makes #5989 obsolete.

[nickva]

The one difference with the #5989 is there grouped_docs always tracks the spawned workers exactly, and one worker's reply never changes other worker's grouped_docs entry behind its back. In other words we have an invariant that grouped_docs[W] always equals what was cast to W, and so we eliminate the function_clause bug by construction, it will never reappear in that place.

The downside is, the other PR adds a conflicts field. But, since this feature in general about reducing conflicts, tracking conflicts explicitly doesn't seem like a bad thing, I found it easier to reason about.

There is actually a separate bug/issue being addressed here and, that is how sws=false behaves in regard to conflict and quorum. Previously (before this PR) we stopped at the first conflict, and that's not exactly the behavior the before the conflict reduction feature was added. The other PR (#5989) didn't address that initially, but I now copied that part from here and it should fix that issue as well (with a test to verify it), but yeah even there it means threading the flag through quite a few functions.