New error predicate type for errors that can be caused by doing too much work in a single transaction

There are a class of errors (some of which are retriable) that can be caused if the user attempts to do too much in a single transaction. It is possible that a user might want to do something different if they encounter this kind of error rather than simple retrying their operation. For example, you could imagine a use-case where the user tries to process a large range of keys and then do something with the aggregated keys. If they get an error like `transaction_too_old`, they might want to retry their read but read a smaller range to avoid hitting that limit in the retry.

I think a list of error codes that could be in this category would be:

* `transaction_too_old`
* `transacation_timed_out`
* `transaction_too_large`

An error code on the fence might be `not_committed`. If a commit is getting a `not_committed` error, then it means that there was a conflict, which does not strictly mean that doing too much work caused the `not_comittted` error. However, if this is, for example, attempting to aggregate a large range of keys, then it's possible that by retrying the previous transaction while doing less work, then on the retry, the transaction will hit fewer keys and thus suffer fewer conflicts (as well as complete faster, which can also help).

The issue names no files, tests, or entry points. Start by locating the existing error predicate definitions and error-code tests, then determine how the proposed category should represent transaction_too_old, transacation_timed_out, and transaction_too_large. Done means the predicate behavior and its treatment of not_committed are defined, implemented, and covered by tests.

Written by the indexing model from the issue text.