Add context.Context to methods defined in chain, prover, and signer module interfaces

[abicky]

Description

This PR is the first step to integrate with OpenTelemetry to improve the observability of yui-relayer.
I will divide the whole integration process into the following phases:

1. Add a context.Context argument to the methods defined in chain module interfaces, prover module interfaces, and signer module interfaces
2. Fix method signatures of the modules in other repositories
   • Add context.Context to Signer methods datachainlab/ibc-hd-signer#3
   • Add context.Context to Chain methods datachainlab/ethereum-ibc-relay-chain#63
   • Add context.Context to Prover methods datachainlab/ethereum-ibc-relay-prover#32
   • Add context.Context to Prover methods and Signer methods datachainlab/lcp-go#40
   • Add context.Context to Prover methods datachainlab/besu-ibc-relay-prover#15
   • Add context.Context to Chain methods and Prover methods datachainlab/ibc-parlia-relay#51
3. Add a context.Context argument to appropriate methods that are unlikely to be used from other repositories
   • e.g. methods of core.StrategyI, core.SyncHeaders, and so on
   • Resolve context.TODO() and add context argument #154
4. Replace context.TODO() with an appropriate context
   • Use context appropriately datachainlab/ethereum-ibc-relay-chain#64
   • Use context appropriately datachainlab/ethereum-ibc-relay-prover#35
   • Use context appropriately datachainlab/ibc-parlia-relay#56
   • Use context appropriately datachainlab/besu-ibc-relay-prover#16
   • Use context appropriately datachainlab/lcp-go#43
5. Integrate with OpenTelemetry
   • Integrate with OpenTelemetry #162
   • Integrate with OpenTelemetry logs #163
   • Support tracing feature datachainlab/ethereum-ibc-relay-chain#66
   • Support tracing feature datachainlab/ethereum-ibc-relay-prover#38
   • Support tracing feature datachainlab/ibc-parlia-relay#61
   • Support tracing feature datachainlab/lcp-go#51

This PR includes the changes in the first phase and I have added a context.Context argument to the methods likely to access external services or create a goroutine, and context.TODO() to the method calls in a mechanical manner.
Although the main purpose is to improve the observability, I think it is common to add a context.Context argument to such methods, whose process we need to cancel in some occasions.

Note that I don't add a context.Context argument to the methods that are likely to be a mere getter.

Considerations

This PR includes breaking changes, but they are acceptable according to Module version numbering:

Signals that the module is still in development and unstable. This release carries no backward compatibility or stability guarantees.

Note

I have examined the following interfaces:

% git grep -E 'type \w+ interface \{' ':!chains'
config/module.go:9:type ModuleI interface {
core/chain.go:59:type Chain interface {
core/chain.go:96:type ChainInfo interface {
core/chain.go:114:type MsgEventListener interface {
core/chain.go:120:type IBCQuerier interface {
core/chain.go:127:type ICS02Querier interface {
core/chain.go:137:type ICS03Querier interface {
core/chain.go:143:type ICS04Querier interface {
core/chain.go:173:type ICS20Querier interface {
core/chain.go:181:type LightClientICS04Querier interface {
core/chain.go:187:type QueryContext interface {
core/config.go:28:type ConfigI interface {
core/config.go:50:type ChainConfig interface {
core/config.go:57:type ProverConfig interface {
core/headers.go:12:type Header interface {
core/headers.go:19:type SyncHeaders interface {
core/headers.go:37:type ChainInfoLightClient interface {
core/headers.go:43:type ChainLightClient interface {
core/msg.go:11:type MsgID interface {
core/msg.go:17:type MsgResult interface {
core/msg.go:30:type MsgEventLog interface {
core/provers.go:13:type Prover interface {
core/provers.go:28:type StateProver interface {
core/provers.go:38:type LightClient interface {
core/provers.go:57:type FinalityAware interface {
core/provers.go:64:type FinalityAwareChain interface {
core/provers.go:70:type ChainInfoICS02Querier interface {
core/strategies.go:9:type StrategyI interface {
metrics/metrics.go:30:type ExporterConfig interface {
signer/signer.go:9:type SignerConfig interface {

And here is my note on whether to add a context argument:

• Chain
  • This interface embeds ChainInfo, IBCQuerier, and ICS20Querier
  • Example implementations:
    • github.com/datachainlab/ethereum-ibc-relay-chain/pkg/relay/ethereum.Chain
    • github.com/hyperledger-labs/yui-relayer/chains/tendermint.Chain
  • All the methods of IBCQuerier and ICS20Querier have QueryContext containing context.Context as the first argument, so we don't need to change the signature
  • Other methods except for SendMsgs, GetMsgResult, LatestHeight, and Timestamp are expected to be simple getters, setters, or fixed values, so we don't need a context
• MsgEventListener
  • I could not find any implementations but some modules may access external services, so I have added a context.Context argument
• ConfigI
  • The method UpdatePahtConfig is unlikely to access external services or create a goroutine, so we don't need to change the signature
• ChainConfig
  • The methods Build and Validate are likely to be so simple that we don't need a context
• ProverConfig
  • Same as ChainConfig
• SyncHeaders
  • This interface is used internally, so I won't change the signatures for now, and I will change them in another PR
• MsgID
  • Is_MsgID is just used for an annotation to indicate that the struct is a kind of MsgID
• MsgResult
  • The methods are usually mere getters of struct fields
• MsgEventLog
  • is_MsgEventLog is just used for an annotation to indicate that the struct is a kind of MsgEventLog
• Prover
  • Almost all the methods usually access blockchain nodes, so I have added a context.Context argument
• StrategyI
  • Same as SyncHeaders
• ExporterConfig
  • This interface is used internally
• SignerConfig
  • Same as ChainConfig
• Signer
  • These methods can access external services, for example, in the case HSM is used
    • https://docs.web3j.io/4.8.7/advanced/HSM_transaction_signing/ is an example that uses HSM to sign a transaction

[abicky]

@bluele @siburu Can you take a look?

[siburu]

@abicky Thank you for your careful consideration. Basically OK, but I noticed that Chain.Timestamp and Prover.CreateInitialLightClientState take both context.Context and ibcexported.Height as arguments. Therefore wouldn't it be more natural for these functions to accept a single QueryContext argument instead?

[abicky]

@siburu Thank you for your feedback!
My understanding is that QueryContext is used for an option when a client sends a request to a blockchain node as follows:

• https://github.com/cosmos/ibc-go/blob/v8.2.1/modules/core/client/query.go#L16-L68
• https://github.com/datachainlab/ethereum-ibc-relay-chain/blob/v0.3.14/pkg/relay/ethereum/chain.go#L533-L535

If I'm correct, it is not appropriate to use QueryContext for Timestamp and CreateInitialLightClientState because the height is an argument of the method, not an option for a RPC request.

Here are also some example methods that take both of a context and a height as their arguments:

• core.StateProver.ProveHostConsensusState
• core.ICS02Querier.QueryClientConsensusState

[siburu]

Sorry for the late review. LGTM. Thank you!

[bluele]

LGTM👍

[mizuochik]

LGTM!

Although SyncHeaders and StrategyI support for contexts is important for trace implementation, I understand it's a different PR.