feat: allow awaiting payload in progress

[klkvr]

Closes #11716

Added wait_for_pending argument to resolve methods which allows to configure whether returned future should wait for a payload job in progress.

Added resolve method and removed unused new_payload and send_and_resolve_payload methods from PayloadBuilder trait.

[mattsse]

I'd like to introduce an enum that represents the requested payload kind, this way could easier change this in the future and an enum is generally better for this than a bool arg

[mattsse]

I'd prefer an enum instead of the bool that represents the targeted payload kind

[mattsse]

a few more suggestions

[mattsse]

this isn't quite right, from CL pov we want a payload as fast as possible, so where this would be relevant is if there's no best payload yet we start racing the empty payload against the in progress payload:

reth/crates/payload/basic/src/lib.rs

Lines 545 to 546 in b77265e

	/// If no payload has been built so far, it will either return an empty payload or the result of the
	/// in progress build job, whatever finishes first.

so this mode is more like Earliest

[mattsse]

I want to keep this non breaking because this is currently used by users.

we should instead introduce a new function that accepts the kind and resolve calls this with Kind::Earliest

[mattsse]

same pattern here, basically just as:

reth/crates/net/network-api/src/lib.rs

Lines 131 to 138 in b77265e

	/// Adds a peer to the known peer set, with the given kind.
	fn add_peer_kind(
	&self,
	peer: PeerId,
	kind: PeerKind,
	tcp_addr: SocketAddr,
	udp_addr: Option<SocketAddr>,
	);

reth/crates/net/network-api/src/lib.rs

Lines 121 to 124 in b77265e

	/// Adds a trusted peer to the peer set with TCP `SocketAddr`.
	fn add_trusted_peer(&self, peer: PeerId, tcp_addr: SocketAddr) {
	self.add_peer_kind(peer, PeerKind::Trusted, tcp_addr, None);
	}

reth/crates/net/network-api/src/lib.rs

Lines 106 to 109 in b77265e

	/// Adds a peer to the peer set with TCP `SocketAddr`.
	fn add_peer(&self, peer: PeerId, tcp_addr: SocketAddr) {
	self.add_peer_kind(peer, PeerKind::Static, tcp_addr, None);
	}

[mattsse]

here we don't need to pass the kind as argument instead we can control it based on whether we set the empty_payload
if Kind.is_earliest then we can keep this as none so the ResolveBestPayload will only race the two real payloads against each other

[klkvr]

rn if payload job is still in progress ResolveBestPayload would always return the best_payload, so we need to somehow make it poll the pending one until completeion I think?

[mattsse]

imo this is fine, because you still want to return as fast as possible and if we already have one we should probably return that asap, the pending could even be the same or is not guaranteed to be better

[klkvr]

updated, though I think there's an edge case when pending job fails leaving us with nothing to return

but given this is only used in --dev mode for now I think it should be OK

[mattsse]

lgtm