Create MultiNode Adaptor

[DylanTinianov]

Description

Ticket: https://smartcontract-it.atlassian.net/browse/BCFR-1071

Most of the code in the Solana MultiNodeClient can be reused by all chain integrations. This PR extracts all of the chain-agnostic client code through making a generic MultiNodeAdaptor. This will further extract functionality into the MultiNode and reduce new integration cost.

Generic MultiNodeAdaptor:

type MultiNodeAdaptor[HEAD Head] struct {
	cfg         *mnCfg.MultiNodeConfig
	stateMu     sync.RWMutex // protects state* fields
	subsSliceMu sync.RWMutex
	subs        map[Subscription]struct{}
    chStopInFlight chan struct{}
	chainInfoLock sync.RWMutex
	highestUserObservations ChainInfo
	latestChainInfo ChainInfo
	
	// chain-specific functions will be passed in
	latestBlock          func(ctx context.Context) (HEAD, error)
	latestFinalizedBlock func(ctx context.Context) (HEAD, error)
}

The the following methods can all be chain-agnostic and extracted:

RegisterSub(sub Subscription, stopInFLightCh chan struct{}) 
LatestBlock(ctx context.Context) (HEAD, error) 
LatestFinalizedBlock(ctx context.Context) (HEAD, error) 
SubscribeToHeads
SubscribeToFinalizedHeads
OnNewHead
OnNewFinalizedHead
AcquireQueryCtx
UnsubscribeAllExcept
Close
GetInterceptedChainInfo

All other client methods will still be implemented on the chain specific side including:

Dial(ctx context.Context) error 
IsSyncing()
Ping(ctx context.Context) 
SendTxResult

[pavel-raykov]

what does this mutex protect?

[DylanTinianov]

Both ChainInfo structs below it (highestUserObservations and latestChainInfo)

[pavel-raykov]

Would you think it makes sense to spell it explicitly?

[DylanTinianov]

How so?

[pavel-raykov]

Right now, it might seem (unless you read the code) that chainInfoLock might only protect latestChainInfo. So, I think spelling out the protected fields explicitly would help here.

[DylanTinianov]

Updated and prefixed both fields with chainInfo

[pavel-raykov]

The type is already there (ChainInfo), so I don't think the prefix is necessary - you can just comment that they are both protected by chainInfoLock.

[pavel-raykov]

Adaptor

Sorry, the naming seems strange - the Adapter pattern (https://refactoring.guru/design-patterns/adapter) usually helps to convert one interface to another; in this case, however, this functionality seems more like a common part - may be a "SubscriberManager"?

[DylanTinianov]

Adaptor

Sorry, the naming seems strange - the Adapter pattern (refactoring.guru/design-patterns/adapter) usually helps to convert one interface to another; in this case, however, this functionality seems more like a common part - may be a "SubscriberManager"?

This component adapts chain-specific client interfaces to the RPCClient interface used by MultiNode. I think the name makes sense here for the use case. I don't feel like "SubscriberManager" really describes what this component is used for.