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.

namada/shared/src/types/vote_extensions/ethereum_events.rs

Lines 21 to 31 in a669ca5

	pub struct Vext {
	/// The block height for which this [`Vext`] was made.
	pub block_height: BlockHeight,
	/// TODO: the validator's address is temporarily being included
	/// until we're able to map a Tendermint address to a validator
	/// address (see <https://github.com/anoma/namada/issues/200>)
	pub validator_addr: Address,
	/// The new ethereum events seen. These should be
	/// deterministically ordered.
	pub ethereum_events: Vec<EthereumEvent>,
	}

[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 dc2586d 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