Remove validator address fields from vote extensions once we switch to ABCI++

[james-chf]

Once we switch to ABCI++, for vote extensions, we should be able to derive the validator's Namada address from their Tendermint address/key, rather than having to include it in the vote extension itself.

https://github.com/anoma/namada/blob/a669ca573f1d3f61b87cdcb8eba7cb9a6f872a6a/shared/src/types/vote_extensions/ethereum_events.rs#L21-L31

[james-chf]

Some extra context - for initial launch with Tendermint v0.37 where vote extensions are being packaged inside regular transactions, we do need the validator addresses inside the vote extensions, as we can't work them out from the Tendermint address as we won't have that.

With ABCI++ vote extensions, Tendermint will do some signature checking/replay protection for us like that a vote extension from validator X was signed by validator X's Tendermint key. While we are using vote extensions packaged inside regular transactions, we need to explicitly check that they were actually signed over by the validator specified in the address field (we will still do this application level signature check as well when we switch to ABCI++, in addition to the signature checking which Tendermint does - but we may not need the Namada address field anymore since we should be able to derive that from the Tendermint address we receive with each vote extesnion).

Currently (as of commit dc2586dc3f34586fcff02198710e929d07fd6826 in eth-bridge-integration branch), we do this application level signature check at two places:

• when a vote extension transaction is attempted to be added to the mempool via a ledger's CheckTx ABCI method - this catches invalidly signed vote extension transactions from external users (i.e. using namadac) and also other nodes which may be trying to gossip such invalidly signed vote extension transactions - this check won't be applicable anymore once we switch to ABCI++ and stop using vote extension transactions
• during ProcessProposal for any vote extension transactions included in a block proposal - this covers the case where hostile block proposers may directly inject invalidly signed vote extension transactions - we will still do a similar sort of this check when we switch to ABCI++, although all the vote extensions will be compressed into a digest rather than on chain individually