fix(sequencer): allow benchmarks to run on macOS and fix issues

[Fraser999]

Summary

This updates the sequencer benchmarks to actually run on macOS, and fixes a couple of issues around the mempool benchmarks.

Background

The benchmarks could previously only be run on Linux. Since they're also not being run regularly, they got broken at some point.

Since I was working on fixing them anyway, I took the opportunity to improve the initialization of the test data. This has resulted in the total time to execute the full mempool suite dropping from ~6.5 mins to ~1.5 mins and means all tests are now able to complete 100 iterations (several could only manage one iteration previously).

Changes

• Used an item from the astria-sequencer crate in the benchmark's main function to resolve the issue of the tests not running on macOS.
• Fixed an issue where the tests were reusing identical txs, causing initialization to fail with an InsertionError::AlreadyPresent error.
• Memoized test data to reduce test initialization times.
• Refactored PendingTransactionsForAccount::find_demotables to use an existing method, deduplicating code.

Testing

Confirmed the benchmarks ran on macOS locally. The app ones take a very long time to run and this should be investigated and fixed. To run only the mempool ones:

cargo bench --features=benchmark -qp astria-sequencer mempool

Changelogs

No updates required.

Related Issues

Closes #1355.

[SuperFluffy]

Can we rearchitect our benchmarks to move away from Divan toward Criterion instead? I am thinking of breaking out code parts that are benched into free standing crates for example.

I understand one advantage is that Divan makes it relatively easy to bench code that's not in the public API. On the other hand we seem to be needing lots of workarounds for it.

[Fraser999]

@SuperFluffy

Can we rearchitect our benchmarks to move away from Divan toward Criterion instead? I am thinking of breaking out code parts that are benched into free standing crates for example.

Yes, but I'm not sure if we should in the short-term.

The workarounds for Divan are constrained to just the benchmarking code, except for possibly one which would be required for Criterion anyway, so I'm not too worried about them. Most of the workarounds will hopefully no longer be required in the future according to Divan's roadmap, but whether progress is made on that or not is debatable. It does not seem to be under particularly active development.

I'm not convinced that breaking out benchmarked sections of the code into standalone crates is worthwhile though tbh. I don't see a compelling argument for breaking out App or Mempool right now since they're both (rightly) very specific to our use-case in Sequencer. On the plus side, breaking them out would at least (hopefully!) force us away from using eyre in these places, but that just makes the effort to break them out all the greater. Splitting one or both out later could be useful if we decide they could be reused by new apps, but I would avoid it if we don't have that need.

We could instead look to feature gate public access to the required modules behind the existing benchmark feature. It would be a little ugly, but maybe worthwhile given the benefits of Criterion.

[Lilyjjo]

Nice refactor 👍

[Lilyjjo]

This lgtm, great that it runs on macs now :)