feat: api: sanity check the "to" address of outgoing messages

[Stebalien]

Related Issues

Proposed Changes

If the "to" address of an outgoing message is a delegated address, verify that it maps to a valid Ethereum address. This isn't a consensus critical change, but it'll help prevent client-side address conversion libraries from directing messages into oblivion (e.g., by mis-translating 0xff0000.... addresses into f410f... addresses instead of f0... addresses.

Notes:

• We cannot filter these addresses inside pubsub (without a network upgrade) without risking the stability of the pubsub network (all nodes need to agree on which messages are valid and which messages aren't; censorship is treated as an attack).
• We've discussed making it impossible to send funds to "invalid" f4 addresses within the protocol itself, but that has other implications and is a more complicated debate (it means running actor code for method-0 sends in some cases).

Additional Info

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, test
  • area, e.g. api, chain, state, mempool, multisig, networking, paych, proving, sealing, wallet, deps
• If the PR affects users (e.g., new feature, bug fix, system requirements change), update the CHANGELOG.md and add details to the UNRELEASED section.
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[rvagg]

This seems fine to me, but here's my understanding of what it's doing: refusing to receive messages for the message pool from the API. One implication is that it would refuse such messages from the large public RPC providers, which would cut off a large % of the source of these messages (I think).

I'm not sure how the pubsub censorship resistance works though so can't really comment on that. Is there any path to receiving and passing them on but just refusing to pack them into blocks? Or is the packing part of the protocol too?

[aarshkshah1992]

Added the backport label to this so we have it in the v1.28 release.

[aarshkshah1992]

Assigning myself to take this to completion.

[aarshkshah1992]

@Stebalien @rvagg I have added unit tests and an itest to this. Please can you guys approve?

[Stebalien]

LGTM but I can't approve as I created the PR (and someone else should make sure the logic is fine).