feat(graphql): expose available range of data on each query

Part of #12409.

Add the available range to the GraphQL connections that can return an incomplete result because data is missing from the database.

Which connections

Three types. Each is a single type in the schema, so one field on each covers every field that returns it.

TransactionBlockConnection comes from our own ScanConnection (src/connection.rs), which is only ever used for transaction blocks. EventConnection and CheckpointConnection come from async_graphql::connection::Connection, which carries extra fields through Connection::with_additional_fields.

TransactionBlockEffects.events and GenesisTransaction.events list the events of a single transaction that we already hold, so there is no range to report there. The field has to be nullable so those two can leave it out.

Also in scope

Two things that make the new field usable:

• A transactions or events query whose whole range has been pruned returns an empty connection today, which looks the same as no matches. TxBounds::query returns None when the checkpoint row for the lower bound is gone, and Event::paginate has no lower bound check at all. Both should report that the data is pruned, like Query.checkpoints already does.
• Query.availableRange is described as the range of checkpoints the RPC has data for, but it returns the range for consistent object queries only: the objects_backward_history bound, further limited by max_available_range (9000 checkpoints by default). That is much shorter than the range for transactions, events and checkpoints. Fix the wording so the two are not mixed up.

Not in scope

• Consistent object queries: ObjectConnection, MoveObjectConnection, BalanceConnection, CoinConnection, StakedIotaConnection, NameRegistrationConnection, DynamicFieldConnection. They already fail with "Requested data is outside the available range" when the checkpoint is outside the window, and Query.availableRange already reports that window.
• Single object, transaction and checkpoint lookups. They already return an error saying the data was pruned when the historical fallback is not configured.
• Connections built from data already in hand (transaction inputs, object changes, balance changes, Move modules, validators and so on), and MovePackageConnection, which reads packages and is always complete.

Where the value comes from

The watermarks table, which the indexer keeps in memory. GraphQL already reads it through db.inner.watermark_cache() (see types/checkpoint.rs), and get_lowest_available_cp_for_tables returns the bound for a set of tables.

Take the bound from the watermark rows of the tables a query reads, rather than from a fixed list of the tables the pruner deletes from. Two things write those rows:

• the pruner, for the tables it prunes
• a restore from snapshot, which sets a lower bound for every prunable table and also for objects_version, because the restore keeps only the object versions that were live at the end of the snapshot epoch

The upper bound is the checkpoint the query is viewed at, so the existing AvailableRange type fits. Its description needs rewording to cover both uses.

Work

• add the field to ScanConnection, and to the event and checkpoint connections
• map the GraphQL transaction and event filters to the tables they read. IndexerReader::tx_tables_for_filter does this for the JSON-RPC filter types, so the function cannot be reused, but the table sets can be shared
• report pruned data instead of an empty connection
• update schema.graphql and its snapshot test
• tests against a pruned database

Open questions

• whether to report a wider range when the historical fallback is configured
• what to report while the watermarks are still zero after a cold start (#11828)