release-24.3: roachtest: use smaller batch size in schemachange/invertedindex

[blathers-crl]

Backport 1/1 commits from #139538 on behalf of @rafiss.

/cc @cockroachdb/release

---

We've seen this test flake due to the error

workload run error: pq: split failed while applying backpressure to
Put [/Table/106/1/136264000/0], Put [/Table/106/1/136264001/0], Put [/Table/106/1/136264002/0],
Put [/Table/106/1/136264003/0], Put [/Table/106/1/136264004/0], Put [/Table/106/1/136264005/0],
Put [/Table/106/1/136264006/0], Put [/Table/106/1/136264007/0], Put [/Table/106/1/136264008/0],
Put [/Table/106/1/136264009/0], Put [/Table/106/1/136264010/0], Put [/Table/106/1/136264011/0],
Put [/Table/106/1/136264012/0], Put [/Table/106/1/136264013/0], Put [/Table/106/1/136264014/0],
Put [/Table/106/1/136264015/0], Put [/Table/106/1/136264016/0], Put [/Table/106/1/136264017/0],
Put [/Table/106/1/136264018/0], Put [/Table/106/1/136264019/0],... 976 skipped ...,
Put [/Table/106/1/136264996/0], Put [/Table/106/1/136264997/0], Put [/Table/106/1/136264998/0],
Put [/Table/106/1/136264999/0], EndTxn(parallel commit) [/Table/106/1/136264000/0],
[txn: d657bdfb], [can-forward-ts] on range r94:/{Table/106/1/127030358-Max}
[(n3,s3):1, (n2,s2):2, (n4,s4):3, next=4, gen=66]: operation "split queue process replica 94"
timed out after 1m5.577s (given timeout 1m0s): failed to re-compute MVCCStats pre split:
result is ambiguous: after 46.48s of attempting command: context deadline exceeded

This error is more likely to happen with large inserts, and when the cluster is under load.

We can reduce the chance of this error occurring by using a smaller batch size. A batch size of 1000 would mean somewhere on the order of 15 MB/s was being inserted, so with a batch size of 200, it should be on the order of 3 MB/s.

fixes #138891
fixes #139320

Release note: None

---

Release justification: test only change

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Backports should only be created for serious
  issues or test-only changes.
• Backports should not break backwards-compatibility.
• Backports should change as little code as possible.
• Backports should not change on-disk formats or node communication protocols.
• Backports should not add new functionality (except as defined
  here).
• Backports must not add, edit, or otherwise modify cluster versions; or add version gates.
• All backports must be reviewed by the owning areas TL. For more information as to how that review should be conducted, please consult the backport
  policy.

If your backport adds new functionality, please ensure that the following additional criteria are satisfied:

• There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
• The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
• New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters. State changes must be further protected such that nodes running old binaries will not be negatively impacted by the new state (with a mixed version test added).
• The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.
• Your backport must be accompanied by a post to the appropriate Slack
  channel (#db-backports-point-releases or #db-backports-XX-X-release) for awareness and discussion.

Also, please add a brief release justification to the body of your PR to justify this
backport.

[cockroach-teamcity]

This change is