services/horizon: make our fork of throttled the primary dependency

[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

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

Make @bartekn's fork of the throttled dependency the primary dependency for that dependency instead of being just a custom source, which is now hosted at github.com/stellar/throttled.

Goal and scope

This is part of the initiative to move to Modules (#1634) and is a small change to simplify our Gopkg.toml/lock files to make that transition possible and simpler.

Using the fork seems to be confusing the go tooling in go1.12 and go1.13rc1, with both behaving a little differently. There is an issue open golang/go#33795 about it. The issue seems to be limited to replacing modules that don't have a go.mod, which is the case with the throttled module. Since this fork is the only fork of a dependency we use and it is simple package, it is straight forward for us to switch to using the fork fully in name rather than to try and make it work consistently with both versions, and we did that in bartekn/throttled#2. See that issue for more details about why we felt like this is the right move.

For context, in modules a replace directive is how we tell the go toolchain that we want to use a fork of a module. However, a replace statement only applies when go commands are executed inside this repo as the main module and so importers of our repo won't be using the fork. This doesn't really matter for throttled because we only use it in internal and main modules of horizon, but because of this the go toolchain does care about the original source since importers of our repo will get the original source, not the replacement.

Important

The revision of stellar/throttled that we are importing did change. You can see the diff here:
stellar/throttled@c99eef3...89d7581

Summary of changes

• Replace github.com/throttled/throttled as a dependency with github.com/stellar/throttled so that it is the name of the dependency and not just the source used to retrieve the dependency.
• Replace github.com/throttled/throttled in import paths with github.com/stellar/throttled.
• Change the revision of github.com/stellar/throttled to include additional commits, see diff above.

Known limitations & issues

• This pattern of entirely replacing a package with a fork isn't a pattern we can use in every situation. If we were using a fork of a more complex package with sub-packages those sub-packages would still reference it. This is a pattern we have the luxury of using with this simple package, and if the package was more complex we'd have to find a more complex solution or possibly work with the developers of the go toolchain to identify the precise way forward.

What shouldn't be reviewed

[TODO]

Related

This change supersedes #1636.

[MonsieurNicolas]

should we use a stellar fork instead of bartekn ?

[leighmcculloch]

@MonsieurNicolas We could. The fork's README needs tidying up, and I'm not sure if we want to promote it as 'Stellar has this thing you should use' because @bartekn has some ideas on how his fixes in the fork could be done in a way that would be easier to propose to the upstream repo. Long term that might be better to pursue getting fixes merged upstream and swapping back to it?

[msfeldstein]

I'm ok with this, it looks like throttled isn't a very active project so I'm not worried about maintenance in the short term. If we actually have plans to push fixes upstream I don't think we should jump through the hoops of making a stellar project.

[leighmcculloch]

I'm using a revision here and not a tag because it's a little confusing to introduce tags into our stellar/throttled fork if we plan for it to converge with upstream someday. This commit is on the stellar branch of that repo where our commits live.

[tomquisel]

LGTM!