adapter: Lazily deserialize the audit log

[jkosh44]

On startup the adapter reconciles the contents of most builtin tables
via the following procedure:

1. Read in the updates from the relevant durable catalog collection.
2. Generate builtin table updates from the updates.
3. Read in the current contents of the builtin table.
4. Generate builtin table retractions from the current contents.
5. Consolidate the two sets of builtin tables updates.
6. Append the consolidated builtin table updates to the builtin
   table.

The audit log is extremely large and deserializing all updates in step
(1) can take an extremely long time. Previously, this deserialization
was done in a background thread to try and hide some of the latency.

The audit log is append only and un-migratable, so the above process is
very wasteful. We know that most of the updates from step (1) will
cancel out with all updates from step (3) and we'll only be left with a
small amount of additions to the builtin table. In the common happy
case, they'll cancel out completely.

This commit special cases the reconciliation process for the audit log
so that it follows the following optimized procedure:

1. Read in the audit log updates from the durable catalog, but don't
   deserialize any events.
2. Read in the current contents of mz_audit_events.
3. Sort mz_audit_events by ID and find the largest ID.
4. Only deserialize the audit log updates from the durable catalog,
   that have an ID larger than the max ID.
5. Generate builtin table updates from the deserialized updates.
6. Append the updates to mz_audit_events.

Note: When/if we make the durable catalog shard queryable via SQL, then
we can remove the entire reconciliation process (including the contents
of this commit), which will be a huge win for startup times.

Works towards resolving #MaterializeInc/database-issues/issues/8384

Motivation

This PR adds a known-desirable feature.

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

[jkosh44]

In my staging account, this saves about 2 - 2.5 seconds during startup. Specifically my startup times go from roughly 19.8 seconds to 17.45 seconds.

[jkosh44]

This doesn't contribute to downtime, so it's not that important.

[ParkMyCar]

neat!