internal/ethapi: add eth_SendRawTransactionSync

[aodhgan]

New RPC method eth_sendRawTransactionSync(rawTx, timeoutMs?) that submits a signed tx and blocks until a receipt is available or a timeout elapses.

Two CLI flags to tune server-side limits:

--rpc.txsync.default (default wait window)

--rpc.txsync.max (upper bound; requests are clamped)

Creates a SubscribeTransactionReceipts subscription to monitor and extract desired receipts.

Success/timeout unit tests added.

closes #32094

[s1na]

We can do a slight refactor with this PR merged: #32697 (comment)

[s1na]

We can do a slight refactor with this PR merged: #32697 (comment)

This PR was merged ^

[Sahil-4555]

@s1na @gawnieg
According to the EIP-7966, if a transaction is not ready to be processed, the handler should return error code 5 along with an error message. I checked the SubmitTransaction function but didn’t see this implemented—should it be added here or handling elsewhere?

[aodhgan]

@s1na @gawnieg According to the EIP-7966, if a transaction is not ready to be processed, the handler should return error code 5 along with an error message. I checked the SubmitTransaction function but didn’t see this implemented—should it be added here or handling elsewhere?

The given examples (missing nonce or insufficient funds) are already covered by their own more granular codes (https://github.com/aodhgan/go-ethereum/blob/ag/feat/add-ethsendRawTransactionSync/internal/ethapi/errors.go#L102). There is an option to coalesce these into the new error code 5 but dont see much value? (Also considering the EIP says SHOULD (vs MUST)). The "node not ready to accept new transactions" seems to require a deeper set of changes? wdyt @s1na?

[aodhgan]

moved to avoid circular dependency

[Sahil-4555]

The given examples (missing nonce or insufficient funds) are already covered by their own more granular codes (https://github.com/aodhgan/go-ethereum/blob/ag/feat/add-ethsendRawTransactionSync/internal/ethapi/errors.go#L102). There is an option to coalesce these into the new error code 5 but dont see much value? (Also considering the EIP says SHOULD (vs MUST)). The "node not ready to accept new transactions" seems to require a deeper set of changes? wdyt @s1na?

Got it, that makes sense. Since the EIP says SHOULD and not MUST, it’s optional. I just wanted to check if we plan to follow that or keep using the current detailed error codes.