Set the number of threads up front in db_stress

[ltamasi]

Summary:
With the code on main, RunStressTest increments the number of threads
one by one as the threads are created and started. This results in a
data race with NonBatchedOpsStressTest::VerifyDb, which reads this
value without synchronization, and is also not correct in the sense
that VerifyDb assumes that the number of threads already has its final
value set (e.g. it's checking whether the current thread is the last
one). The patch fixes this by setting the number of threads before
creating/starting any threads. This also eliminates the need for locking
the mutex during thread startup.

Test Plan:
Ran the blackbox crash test under TSAN for a while.

[facebook-github-bot]

@ltamasi has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[ajkr]

which reads this value without synchronization, and is also not correct in the sense
that VerifyDb assumes that the number of threads already has its final value set

The latter problem seems a consequence of the former, because if it had synchronized it would only be able to read the final value (because lock is held until all threads are created). Anyways this fix LGTM

[ltamasi]

The latter problem seems a consequence of the former, because if it had synchronized it would only be able to read the final value (because lock is held until all threads are created). Anyways this fix LGTM

Thanks for the review! I mentioned the second issue separately because there are other ways of making the code race-free (namely, making the counters atomic) but that still wouldn't be correct for the purposes of computing the key range in VerifyDb. But yeah, locking the mutex there as well would also solve both problems