When we have broken transaction data in the database (such as from
mongo getting OOM killed), it can cause cascade failure, where that
document ends up getting too many transactions queued up against it.

This can also happen if you have nothing but assert-only transactions against a
single document.

If we have lots of transactions, it becomes harder and harder to add
new entries and clearing out a large queue is O(N^2) which means capping it
is worthwhile. (It also makes the document grow until it hits max-doc-size.)

The upper bound is still quite large, so it should not be triggered if
everything is operating normally.

Still defaults to 1000 without any other configuration, but
allows callers to know that they can be stricter/less strict.

…that runs out of queue space.

This still aborts the transaction, but then returns a custom error
instead of ErrAborted. That allows us to still log the details, which
lets us know what document is broken, but also avoids having a huge
queue of Pending transactions wanting to be applied.