SignModeHandler's `GetSignBytes`: add Context arg

[amaury1093]

Summary

	// GetSignBytes returns the sign bytes for the provided SignMode, SignerData and Tx,
	// or an error
-	GetSignBytes(mode signing.SignMode, data SignerData, tx sdk.Tx) ([]byte, error)
+	GetSignBytes(context.Context, mode signing.SignMode, data SignerData, tx sdk.Tx) ([]byte, error)

Problem Definition

In SIGN_MODE_TEXTUAL, when generating signatures (from a client) or verifying signatures (from the antehandler), we need to have access to the latest state. This can only be done if the sign mode handler has access to the context.Context at the point of generating/verifying the signature.

Proposal

Add context.Context argument to GetSignBytes.

Some notes:

• Existing sign modes will not use the new context.Context arg.
• On the antehandler-side, the first arg will be sdk.WrapContext(sdkCtx). The VerifySignature function also needs this new argument.
• On the client-side, it can be context.Background() or some client-created context
• This should in general be an internal SDK method, so shouldn't impact SDK users much

[alexanderbez]

What state or data does it need?

[amaury1093]

By default, only for coins, i.e. the bank metadata. But chains can add custom renderers, for example Agoric wants to show a 1:1-mapped pet name instead of an address in some places.

[tac0turtle]

Is this a opt in thing or break the world everyone needs to add it?

[amaury1093]

It's API breaking. But the only breaking changes are on VerifySignature and SignModeHandler. Not a lot of users interact with them I think. Maybe only evmos because they have their own sign mode handler.

[tac0turtle]

ah, sorry I confused it with another function with the same name

[aaronc]

@AmauryM couldn't we just do this in the SignModeHandler interface we put in the tx module? Or are we planning for tx to import the SDK?

[amaury1093]

Or are we planning for tx to import the SDK?

My idea was for the SDK to import tx. We need to add a new handler in x/auth/tx as done in #12077, then and modify here. IMO this is the path with least code change.