feat(payload): add support for stack of payload builders

[aroralanuk]

Problem

We need a flexible way to combine and sequentially execute multiple payload builders of the same type, allowing for more complex and customizable payload building strategies. Fixes #10438

Solution

Implement a new PayloadBuilderStack<L, R> that can hold and execute two builders of potentially different types in sequence, with the ability to nest these stacks for more complex arrangements.

Implementation Details

• Create PayloadBuilderStack<L, R> with two generic type parameters for left and right builders
• Allow for nested stacks, enabling complex arrangements like Stack<Stack<A, B>, C>

Testing

• None

[nkysg]

no just something that wraps two instances of the same kind (ethereum eg)
similar to https://docs.rs/tower/latest/tower/layer/util/struct.Stack.html
the idea here is that you can use two diff payload builders
and the attributes would be an Either<A, B> where A,B are the payload attributes types of the respective payload builders

Originally posted by @mattsse. FYI @aroralanuk

[Rjected]

I think the original issue requested a stack where you could use more than one type of payload builder - in this, because of the single generic, you can only do multiple of one type of payload builder. So this needs to be changed to support two different payload builders with two different types

[gakonst]

Don't think this works because it assumes all builders are the same type?

[mattsse]

take a look at this type for reference:

https://docs.rs/tower/latest/tower/layer/util/struct.Stack.html

because this has two instances, this allows "stacking" of multiple different types, which can be nested and is very flexible, for example: Stack<Stack<A, B>, C> etc.

A vec would work if all payloadtypes are the same but ideally we can be a bit more flexible here by using two generics

[aroralanuk]

Ok I understand now, will fix soon!

[mattsse]

if we do Stack<A,B> then these could be Either<A,b>:

https://docs.rs/futures/latest/futures/future/enum.Either.html

[mattsse]

and these functions would then do a match on the Either and delegate the to A or B, we likely needs some mapper helpers on BuildArguments and Outcome

[mattsse]

these changes we don't need, because those are independent of the payloadbuilder type itself

[aroralanuk]

Both L and R can be different implementations of PayloadBuilder<Pool, Client> but R must have the same Attributes and BuiltPayload associated types as L. This makes it simpler then to have Either<L,R> which would require us to implement PayloadBuilderAttributes for Either<L::Attributes, R::Attributes> and similarly for Either<L::BuildPayload, R::BuildPayload> and this felt a bit unnecessary.

@mattsse does this feel still too restrictive, we can do:

type StackAB = PayloadBuilderStack<BuilderA, BuilderB>;
type StackABC = PayloadBuilderStack<StackAB, BuilderC>;
type StackABCCA = PayloadBuilderStack<StackABC, PayloadBuilderStack<BuilderC, BuilderA>>;

[mattsse]

cool, the last thing that is missing is changing the stack attribute types

[mattsse]

there is now no way to determine which builder should be used, hence we should use Either<L::Attr, R::Atrr> here

ref https://github.com/paradigmxyz/reth/pull/11004/files#r1768054937

[aroralanuk]

It's a bit more verbose now (with the PayloadBuilderAttributes and BuiltPayload implementation for Either and map_payload), but it uses Either<L::Attr, R::Attr> now. @mattsse

[Rjected]

While it might be code duplication, we're not really implementing Future for an either type here, so it seems better to just hand roll an Either type for the crate and implement Error / PayloadBuilderAttributes / BuiltPayload on it. It would help naming as well

[aroralanuk]

Friendly ping @Rjected @mattsse :)

completed

[aroralanuk]

@mattsse Can you merge this?

[mattsse]

ah oops, forgot to pull the trigger

ty and sorry for the long delay on this -.-