chore: Revert "feat(hyp-ethereum): gas escalator middleware (#3852)"

[daniel-savu]

This reverts commit c3c002a.

Description

The gas escalator took up to 28gb of memory, and even though it was only ever released on RC, it must have taken up too many cluster resources, ending up starving the hyperlane relayer. Reverting for now until we have a better idea

Drive-by changes

Related issues

Backward compatibility

Testing

[changeset-bot]

⚠️ No Changeset found

Latest commit: e1f0581

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 0.00%. Comparing base (8c8f39a) to head (e1f0581).

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #4098   +/-   ##
=====================================
  Coverage   0.00%   0.00%           
=====================================
  Files          1       1           
  Lines         14      14           
=====================================
  Misses        14      14           

Components	Coverage Δ
core	∅ <ø> (∅)
hooks	∅ <ø> (∅)
isms	∅ <ø> (∅)
token	∅ <ø> (∅)
middlewares	∅ <ø> (∅)

[daniel-savu]

@tkporter suggested that since we build a bunch of short-lived providers, we may end up with "zombie" gas escalator tasks, that are spawned each time the escalator middleware is created (such as when building new providers to fetch message metadata). Note how the join handle isn't stored anywhere here.

Proposed next steps are to capture the JoinHandle and implement Drop on GasEscalatorMiddleware to clean up the escalator task. We'd measure this with tokio-console in e2e by running with dependencyTrace and checking if the number of tokio tasks scales with the number of messages.

A potentially easier fix is to pass a boolean in build_ethereum that specifies whether a signer should be used, and only created one in that case. I think no short-lived provider needs a signer, and when no signer is used there's also no gas escalator middleware being created. Here.