feat(block-producer): batch builder

[Mirko-von-Leipzig]

This PR is intended as a review of the in-progress block-producer redesign. The initial body of work was done on the next-block-producer work, however that initial PR received little scrutiny and thus it makes more sense (to me) to review this one in the context of next proper.

In that context, this PR adds the following pieces:

• A mempool consisting of
  • InflightState to track state
  • TransactionGraph to form a dependency graph between transactions
  • BatchGraph to form a dependency graph of inflight batches
• A simple block builder implementation using this new mempool
• A simple batch builder implementation using this new mempool

The builders reuse the existing DefaultXXX types to minimize the footprint of this PR. Once we've switched over we could refactor these further as needed.

Outstanding work

The work items of #514:

• input and output note state tracking
• data propagation from mempool to batch and block builders
• batch builder with configurable failure/work rate
• block builder with configurable failure/work rate
• extensive tests/docs
  • InflightState
  • InflightAccountState
  • TransactionGraph
  • BatchGraph
  • Mempool
• replacing existing framework
• Support transaction expiration #508

I'll continue expanding test coverage; though I'd appreciate a review already. In particular, anything that is unclear or looks bad in the components I've marked as tested.

I'm also uncertain about the amount of # Panics involved. I could return more errors and raise the panics up, but there are complications where certain actions just can't (trivially) be made atomic and leave the graphs/state in a broken state. And a broken mempool means that we're dead in the water anyway. Thoughts welcome.

[Mirko-von-Leipzig]

One issue that @polydez has made me aware of is that notes must be ordered by transaction order. See here.

I have some refactoring to do to support this properly. Thinking on this some more, likely the simplest is to remove my new input notes type entirely in favor of just passing around the original transaction/notes along with the note witnesses.

Will draft this PR until I've fixed this; right now this would cause confusion as is.

[bobbinth]

One issue that @polydez has made me aware of is that notes must be ordered by transaction order. See here.

Yes, this is how I'm currently thinking about it. But one thing we should do to confirm this is sketch out batch kernel - or at least what we think it'll take as public inputs and what public outputs it'll produce. For example:

• Public inputs could be a commitment to a list of transaction IDs (+ some additional data needed to verify transaction proofs) for the transactions included in the batch. All detailed transaction could be provided via the advice provider.
• Public outputs could be a commitment to a list of updated account IDs, a root of the batch note tree, and a commitment to list of created nullifiers.

[bobbinth]

Looks good! Thank you! I left some comments inline - most are minor, but there are a few where I think transaction validation logic needs to be improved.

[bobbinth]

Looks good! Thank you! I left a few more comments inline.

Once these and the comments from the previous review are addressed, I think we should merge this. If you'd prefer not to merge it into next yet, we can merge into a separate branch. Then we can make more PRs with additional changes against that branch (e.g., the ones discussed here.

[Mirko-von-Leipzig]

I've addressed the review comments; I'll merge this PR into next-block-producer and continue with smaller, more revieawable PRs.