Improve scheduling VDiff streams to speed up VDiff time.

[bluecrabs007]

Issue Description
In a large MoveTables workflow (128 → 128 shards, over 140 billion rows), we encountered persistent "Deadline exceeded" errors when running a VDiff operation. The VDiff job failed to complete even after running for over 24 hours.

Error: (shard 2e-30) deadline exceeded: /vitess/vitess-loadtest-db/global/keyspaces/customer_v8/locks
Error: (shard 38-3a) deadline exceeded: /vitess/vitess-loadtest-db/global/keyspaces/customer_v8/locks

Workaround
We were able to successfully complete the VDiff by manually:

• Stopping all VDiff streams
• Restarting each stream one at a time
• Waiting for each individual stream to complete before starting the next

Using this approach, the full VDiff completed within approximately 5 hours.

VDiff Summary for customer_v8.MigrateData (40e02a01-1fdb-11f0-b0e1-36db5969c9c9)
State:        completed
RowsCompared: 141427827192
HasMismatch:  false
StartedAt:    2025-04-23 18:39:56
CompletedAt:  2025-04-23 22:56:20

Suggestion
It would be beneficial for Vitess to support batched or sequential scheduling of VDiff streams automatically, to avoid lock contention, which seem to be a bottleneck in large-scale workflows.

Environment
Vitess version: v16

[mattlord]

@bluecrabs007 do you happen to have a v23 test cluster available where you could run this test with and without the patch in #18998 ?

VDiff has had A TON of fixes and enhancements since v16. We don't even use Keyspace locks anymore (which may be very hot in your keyspace for a variety of reasons), but instead a workflow lock (so as to coordinate with vreplication when making changes to the workflow).

In the meantime, I'm trying to get a 64 shard cluster setup locally using the local examples combined with generating enough writes so as to slow down the initialization process a bit.