refactor(block-producer): simplify shared mempool

[polydez]

I think, creation of SharedMempool as separated structure doesn't give us any benefits, but makes code more complex. Proposed refactoring in this PR.

By the way, @Mirko-von-Leipzig, do we need additional mutex here? https://github.com/0xPolygonMiden/miden-node/blob/9445ca2276b3ed5d02bf14928adb221fd274562b/crates/block-producer/src/server/mod.rs#L165-L171
According to comment, this can help with rate limiting and queuing of new transaction, but it seems to me that one mutex in SharedMempool is enough to do this job.

[Mirko-von-Leipzig]

By the way, @Mirko-von-Leipzig, do we need additional mutex here?

https://github.com/0xPolygonMiden/miden-node/blob/9445ca2276b3ed5d02bf14928adb221fd274562b/crates/block-producer/src/server/mod.rs#L165-L171

According to comment, this can help with rate limiting and queuing of new transaction, but it seems to me that one mutex in SharedMempool is enough to do this job.

I believe we do need it, my reasoning for this is that we need the batch and block building tasks to have priority access to the mempool.

To elaborate more: the mempool is shared between the block-producer's RPC, batch-builder and block-builder processes. The batch and block processes each have single threaded access to the mempool, however the rpc will likely have thousands of concurrent tasks trying to access the mempool. This would mean the batch and block access to the mempool would be competing with all of these.

This extra mutex forces all of these concurrent rpc connections into a single queue, meaning we effectively only have a single rpc access instead of thousands. Without this mutex the batch and block tasks would be mempool starved. We could instead try find a priority based locking mechanism, but I believe this approach is (1) simpler, and (2) probably sufficient since each has a 1/3 access chance under load.

[Mirko-von-Leipzig]

Thanks I agree this is better, thank you!

[polydez]

@Mirko-von-Leipzig so, the main reason to add second mutex is giving priority access to mempool of batch/block builders. This makes sense, thank you for clarification!