Make ZetaClient modular enough so new chain integration can be added as "plugin"

[lumtis]

Is your feature request related to a problem? Please describe.
We want to support new chains in the future. We currently support signing transactions with the TSS for EVM chains and Bitcoin, supporting new protocols might involve complex changes. Making the ZetaClient modular so new chains can be integrated as a plugin would simplify adding new chains:

• The implementation for the signer could be implemented in a separate repository
• The effort for the integration can be subsidized
• Integrating new chains doesn't involve modifying any other component in the ZetaClient codebase

Describe the solution you'd like

An interface must be clearly defined for what is a chain bridge. We have right now a client and a signer interface. The two would need to be analysed if they are generalizable enough to represent signer for any chain.

Other change might be necessary to make integration easier: example: Start and Stop look related to the actual implementation for the ZetaClient logic, we might consider removing these methods.

// ChainClient is the interface for chain clients
type ChainClient interface {
	Start()
	Stop()
	IsSendOutTxProcessed(sendHash string, nonce uint64, cointype common.CoinType, logger zerolog.Logger) (bool, bool, error)
	SetChainParams(observertypes.ChainParams)
	GetChainParams() observertypes.ChainParams
	GetPromGauge(name string) (prometheus.Gauge, error)
	GetPromCounter(name string) (prometheus.Counter, error)
	GetTxID(nonce uint64) string
	ExternalChainWatcherForNewInboundTrackerSuggestions()
}

// ChainSigner is the interface to sign transactions for a chain
type ChainSigner interface {
	TryProcessOutTx(
		cctx *crosschaintypes.CrossChainTx,
		outTxMan *outtxprocessor.Processor,
		outTxID string,
		evmClient ChainClient,
		zetaBridge ZetaCoreBridger,
		height uint64,
	)
}

grouped in one interface:

type ChainBridge interface {
	Name() string
	Client() ChainClient
	Signer() ChainSigner
}

The logic to retrieve signer should also be refactored to make abstraction of what is EVM chains or Bitcoin chains. Typically, the ChainBridge interface would provide a unique name or identifier, then this identifier is used in the config for the chain to be supported in interoperability.

	signerMap := make(map[common.Chain]interfaces.ChainSigner)
	// EVM signers
	for _, evmConfig := range cfg.GetAllEVMConfigs() {
		if evmConfig.Chain.IsZetaChain() {
			continue
		}
		mpiAddress := ethcommon.HexToAddress(evmConfig.ChainParams.ConnectorContractAddress)
		erc20CustodyAddress := ethcommon.HexToAddress(evmConfig.ChainParams.Erc20CustodyContractAddress)
		signer, err := evm.NewEVMSigner(evmConfig.Chain, evmConfig.Endpoint, tss, config.GetConnectorABI(), config.GetERC20CustodyABI(), mpiAddress, erc20CustodyAddress, logger, ts)
		if err != nil {
			logger.Error().Err(err).Msgf("NewEVMSigner error for chain %s", evmConfig.Chain.String())
			continue
		}
		signerMap[evmConfig.Chain] = signer
	}
	// BTC signer
	btcChain, btcConfig, enabled := cfg.GetBTCConfig()
	if enabled {
		signer, err := bitcoin.NewBTCSigner(btcConfig, tss, logger, ts)
		if err != nil {
			logger.Error().Err(err).Msgf("NewBTCSigner error for chain %s", btcChain.String())
		} else {
			signerMap[btcChain] = signer
		}
	}

	return signerMap, nil

In a place in the code, the list of supported chain bridges would be provided, this list can easily be modified to add support, or remove support for new chains.

chainBridges := []ChainBridge{
	EVMChainBridge,
	BitcoinChainBridge,
	...
	SolanaChainBridge,
}