generic scheduler

[apfitzge]

Problem

• scheduler doesn't allow us to handle non SanitizedTransaction types
• we must kill SanitizedTransaction for performance

Summary of Changes

• abstract receiving and buffering in the scheduler controller and all downstream components

Fixes #

[apfitzge]

Once the other structures/impl for new transaction type are ready there will be a switch here on spawning.

• Receiving and buffering is generic so that we can skip over all deserialization (never pass through ImmutableDeserializedPacket)
• Container is generic because the current impl isn't good if we want to copy as little data as possible. For new tx types, it will wrap the old type with a pre-allocated (separate) container for getting free Bytes spaces to copy our packet data into. Eventually this would go away once we have Bytes upstream, but for now we don't and this is much faster than allocating space or copying a Packet for every tx move.

[jstarry]

nit: don't think visibility change was necessary

[jstarry]

Idk I prefer keeping the Tx generic parameter personally. Feels backwards to be getting it from the ReceiveAndBuffer rather than passing it

[apfitzge]

Idea I had here is that ReceiveAndBuffer's type(s) are a single-point controlling all the inner implementations.

I also think this sort of set up is somewhat necessary with what I have planned.
(See most recent push, Container type is also chosen by the ReceiveAndBuffer).

Old transaction type:

• receive packet batches, deserialize into ImmutableDeserializedPacket
• do filtering, eventually end up with RuntimeTransaction<SanitizedTransaction>
• insert those into the TransactionStateContainer<RuntimeTransaction<SanitizedTransaction>>

New transaction type:

• receive packet batches. get pre-allocated space (BytesMut) from the container, copy bytes of packet, parse (using Bytes).
• do filtering, eventually end up with RuntimeTransaction<ResolvedTransactionView>
• insert those into the the a different container type (WrappedTransactionStateContainer).
  • this wrapping is necessary so that we can get and re-use the Bytes for the transactions

So it doesn't make sense if we have the TransactionViewReceiveAndBuffer and a TransactionStateContainer<..>, because we need slightly different behavior due to the type differences; and they require a slightly different interface as well, since getting free space to work on received packets isn't something the base TransactionStateContainer needs to do.

A lot of this gets simplified once we are receiving Bytes from upstream, because we could just insert those into the TransactionStateContainer. But that's blocked rn because of CUDA stuff (that no one uses) 🫠

[apfitzge]

^ kind of a long winded explanation. let me know if you want to hop on a call to discuss, or if you have questions here it's fine too!