feat: retrieve global provider and block tracker dynamically

[dbrans]

Note

Closed: this PR was a commandeer of @matthewwalsh0's #4004. Passing it back to Matt Walsh.

Explanation (by @matthewwalsh0)

Currently the global provider and blockTracker instances are required as constructor options in the TransactionController.

This means the clients must have the global provider available when the controller instance is created, usually on startup.

In order to support construction of the TransactionController before these are available, to facilitate use cases such as disabling provider access until onboarding is complete, this PR does the following:

• Removes the provider and blockTracker constructor options.
• Adds the getGlobalProviderAndBlockTracker callback option.
• Updates all usages of the global network to retrieve the network client dynamically when required.
• Updates all relevant public methods and helper classes to either gracefully ignore a missing network client, or throw an error.
• Replace the blockTracker, getEthQuery and chainId constructor options in the helper classes with a single getNetworkClient option since all the previous values are either all available or all unavailable, meaning the associated validation becomes much simpler.
• Dynamically create the global nonceTracker when first used since it is an alternate package and still requires a provider argument.
• Dynamically create the MethodRegistry instance since it is also an alternate package and requires a provider argument.
• Move the onBootCleanup logic into the public method initApprovedTransactions so it can be called by the client explicitly when suitable.
• Fix logger used by MultichainTrackingHelper.

Note that any additional complexity or logic surrounding the global network specifically is temporary and can be removed once the clients enable the multichain flag, at which point all network clients and helpers will be dynamically synchronised with the NetworkController state.

Changelog

@metamask/transaction-controller

[PENDING]

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've highlighted breaking changes using the "BREAKING" category above as appropriate

[legobeat]

@metamask/transactions-controller tests are failing.

[legobeat]

Looking at the existing tests, the existing set up with the block tracker and multiple providers looks s bit weird.

• chore(test): Refactor FakeBlockTracker provider injection #4345

[mcmire]

Heads up: We are trying to phase out passing functions to constructors to get information that essentially comes from other controllers. This has always been a legacy pattern, and as we transition controllers fully to BaseController v2, it's better to make use of the messenger system to access information instead.

The globally selected network is captured in NetworkController as the state property selectedNetworkClientId. This property is guaranteed to be present since a network must always be selected at all times. The combination of provider and block tracker is known as a "network client". Therefore, a more future-looking approach would be to allowlist NetworkController:getState and NetworkController:getNetworkClientById for the transaction controller messenger, and then wherever we need to access the network client for the currently selected network, we can say:

const { selectedNetworkClientId } = this.messagingSystem.call('NetworkController:getState');
const networkClient = this.messagingSystem.call('NetworkController:getNetworkClientById', selectedNetworkClientId);

Now we can access networkClient.provider or networkClient.blockTracker as needed. They are guaranteed to point to the same network, since they are created at the same time.

Is it possible to use this pattern for this controller?

[legobeat]

@dbrans Any progress or blockers here?

[dbrans]

• Closing this PR in favor on Retrieve global provider and block tracker dynamically #4004