all: update github.com/rcrowley/go-metrics a5cfc242a56b => 51425a2415d2

[leighmcculloch]

PR Checklist

PR Structure

• This PR has reasonably narrow scope (if not, break it down into smaller PRs).
• This PR avoids mixing refactoring changes with feature changes (split into two PRs
  otherwise).
• This PR's title starts with name of package that is most changed in the PR, ex.
  services/friendbot, or all or doc if the changes are broad or impact many
  packages.

Thoroughness

• This PR adds tests for the most critical parts of the new functionality or fixes.
• I've updated any docs (developer docs, .md
  files, etc... affected by this change). Take a look in the docs folder for a given service,
  like this one.

Release planning

• I've updated the relevant CHANGELOG (here for Horizon) if
  needed with deprecations, added features, breaking changes, and DB schema changes.
• I've decided if this PR requires a new major/minor version according to
  semver, or if it's mainly a patch change. The PR is targeted at the next
  release branch if it's not a patch change.

Summary

Update github.com/rcrowley/go-metrics for transition to Modules (#1634).

From: rcrowley/go-metrics@a5cfc242a56b
To: rcrowley/go-metrics@51425a2415d2

Diff: rcrowley/go-metrics@a5cfc24...51425a2 (41 commits)

Goal and scope

To make the transition to Modules possible. Some dependencies at their current version have incompatible relationships with other dependencies we have. Dep was more tolerant to incompatible versions than Modules. Making this change ahead of the PR that switches us to Modules makes that PR a functional no-op.

The reason Modules is updating go-metrics is because the monorepo is also dependent on github.com/ethereum/go-ethereum which is in turn, via it's tests, dependent on the exp sub-package within go-metrics. The sub-package was added in rcrowley/go-metrics@51425a2.

The go tool in this situation will automatically upgrade go-metrics to it's latest revision since it can see the exp is available there. This PR is however upgrading to the first or oldest revision that contains the sub-package we need to satisfy Modules. We could upgrade to the latest revision but the changes in the smaller diff are much less significant and pose a smaller risk than the changes that are in the diff (rcrowley/go-metrics@a5cfc24...cac0b30 144 commits) to take us all the way to latest.

More details about how this was discovered can be found here: golang/go#33771 (comment)

Summary of changes

• Change the version of the package to the version that Modules selects.

Known limitations & issues

N/A

What shouldn't be reviewed

N/A

[nikhilsaraf]

I'm not familiar with the context of this change so will let @bartekn chime in.
If it's simply a PR to follow process then it seems harmless and I can approve to unblock.

[bartekn]

The change set (rcrowley/go-metrics@a5cfc24...51425a2) looks good to me.