Cache whether a Table is a scheduler table, avoiding fetching the schema

[Centril]

Description of Changes

Fixes #2021.

Does 2 things:

1. changes fn {insert,update}_mut_tx to traits.rs to return whether the table was a scheduler table.
2. adds Table::is_scheduler so datastore_{insert, update}_bsatn don't have to fetch the schema.

Perf before:

for i in {1..5}; do spacetime call basics update_positions_by_collect -s local; done

2025-01-21T04:14:53.970948Z  INFO: : Timing span "update_positions_by_collect": 664.876291ms
2025-01-21T04:14:55.258220Z  INFO: : Timing span "update_positions_by_collect": 651.551835ms
2025-01-21T04:14:56.600896Z  INFO: : Timing span "update_positions_by_collect": 667.1316ms
2025-01-21T04:14:57.722544Z  INFO: : Timing span "update_positions_by_collect": 638.108509ms
2025-01-21T04:14:58.980541Z  INFO: : Timing span "update_positions_by_collect": 642.46669ms

Perf after:

for i in {1..5}; do spacetime call basics update_positions_by_collect -s local; done

2025-01-22T15:21:00.033248Z  INFO: : Timing span "update_positions_by_collect": 663.533985ms
2025-01-22T15:21:01.290030Z  INFO: : Timing span "update_positions_by_collect": 617.702017ms
2025-01-22T15:21:02.417180Z  INFO: : Timing span "update_positions_by_collect": 622.391745ms
2025-01-22T15:21:03.643441Z  INFO: : Timing span "update_positions_by_collect": 618.93754ms
2025-01-22T15:21:04.785486Z  INFO: : Timing span "update_positions_by_collect": 626.819507ms

This means we go from an average 653 ms to 630 ms, which is about an average 23 ms speedup.
This was the expected speedup based on % of samples in the update ABI PR flamegraph.

API and ABI breaking changes

None

Expected complexity level and risk

1, fairly simple and contained change.

Testing

A test of the caching behavior is added in datastore.rs: fn test_scheduled_table_insert_and_update.

[cloutiertyler]

Why are we returning this per insert when we can know whether or not the table we're inserting into is a scheduled table a piori?

[Centril]

Why are we returning this per insert when we can know whether or not the table we're inserting into is a scheduled table a piori?

Semantically, we can check after or before. The previous code did check after, but it is unfortunately slower, as it incurs another table_scheduled_id_and_at -> schema_for_table call, which we can avoid, by sending the information in insert / update instead, essentially for free, since we're fetching the Table there anyways. So the answer boils down to: "semantically, this is not pretty, but it is more efficient".

[cloutiertyler]

Ack, I approve the changes to traits.rs. Please get a full review from the primary reviewer.

[gefjon]

• Why is InsertFlags a distinct type from UpdateFlags?
• Now that we've got insert and update returning a 3-tuple, is it time to switch it to a struct with named fields?

[gefjon]

Approved, pending TODO comments to the effect of my earlier questions.