feat(cast): Add --bypass-sender-recovery flag to cast run for compatibility with hardhat impersonated transactions

[ckoopmann]

Motivation

Currently the code assumes that any impersonated transaction has been signed with a given constant key. (r=1, s=1). If this check is not passed then the from address will be recovered from the tx signature.

This makes cast run incompatible with impersonated transactions on rpc implementations where that assumption does not hold (i.e. when debugging tests in legacy hardhat projects).

Solution

Add a bypass-sender-recovery flag to cast run that makes it such that the from address is always set to the corresponding field on the getTransaction response from the rpc. (and not recovered from the tx signature)

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[ckoopmann]

Note: To fully e2e test this feature you'd have to:

• Start a hardhat rpc node (or other framework that doesn't adhere to the standard impersonation signature)
• Submit a transaction under an impersonated signer
• Run cast run against that tx

I did this locally but wasn't sure if / how to add this to the CI. Lmk if this is critical (or you have a simpler idea of how to test this) and I will look into it further.

[ckoopmann]

Furthermore we might want to add a warning when this flag is not set and the recovered from address differs from the one returned by the getTransaction rpc call as this indicates that something is going wrong. (Originally I had a bunch of "balance too low" or "nonce too high" errors that were quite hard to trace to this root cause).

[ckoopmann]

Note that naming is not entirely consistent here. Elsewhere i call it "bypass sender recovery" whereas here i call it "assume impersonation", happy to change it to either one, or any other naming that improves readability / clairity.