pindexer: implement batch processing API

[cronokirby]

This restructures the AppView interface to allow processing events in a batch. Previously, app views had to index one event at a time. This PR changes things so that app views get a batch of several blocks worth of events, with a guarantee to have all of the events in any block in the batch.

Making App Views Easier to Write

By having access to all the events in a block, app views are more ergonomic to write. For example, the dex explorer app view wants to know the time of the candlestick events it processes, but to do this, it needs to wait for the block root event later in the block, which provides this timestamp. Currently, because we don't have access to any context, we need to manually implement a queuing system in the database, which is very annoying, and a performance hit.

Making App Views More Performant

We can make app views more performant by processing both an entire block, and multiple blocks, since:

• we don't need to write an update more than once per block to the database
• we may be able to write updates less frequently, depending on the app view (e.g. when we need only the current value)
• we can keep transient state in memory, instead of on the database, reducing writes and reads in all cases

Additional Performance Improvements

Now the app views are run in parallel, which provides additional improvements when syncing up.

Testing

Pindexer should work as usual, after wiping the database.

Checklist

• I have added guiding text to explain how a reviewer should test these changes.

• If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason:

  pindexer only

[hdevalence]

Processing each event individually (the status quo) definitely feels suboptimal. I designed it like that originally just for convenience to get something working.

One high-level design question though is whether the AppView should process blocks individually or in batches of blocks (like this PR). Does pushing the batching into the AppView increase complexity or is it manageable?

[cronokirby]

I think the complexity offloaded onto the AppViews is actually minimal, because they can "opt out" by:

• iterating over all events, processing them one-by-one (this is what I've done in the PR for minimal changes)
• iterating over all blocks, processing them block by block

So this allows us to only ever need to tinker with this for app views that are particular causes of slow syncing.

[cronokirby]

Furthermore, a lot of app view workloads look like:

1. read current state from the database
2. process event
3. write information to the database
4. write state to the database
   in which case batch processing is pretty easy to implement to reduce write loads substantially, by just moving 1 and 4 outside of the event processing loop to only be done once per batch