support/http: allow services to specify the logger used by the logging middleware

[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.

What

Allow services to specify the logger used by the logging middleware.

Why

LoggingMiddleware gets the logger from the context using "support/log".Ctx(...). If none is specified in the context the "support/log".DefaultLogger is used. Because the LoggingMiddleware is placed into the chi.Mux in the NewMux and NewAPIMux functions a service using these functions has no opportunity to set a logger on the context because a middleware cannot be inserted earlier. This means by using NewMux and NewAPIMux you are stuck with the default logger.

Why Behind the Why

The reason I'm wanting this is because webauth and recoverysigner are similar to ticker in that they explicitly define all their dependencies and pass them down to the code using them as explicitly as possible. Because of this both of those applications define their own logger. Because we have some code like the LoggingMiddleware that magically pulls the logger out of the context setting it in the context is the only way to fully use a custom logger.

Alternative Implementations

If you look at the commits on this PR I attempted to implement this one way first using functional options. It seems pretty cool 😎 but more complicated that is necessary so I dropped it.

Known limitations

N/A

[accordeiro]

We had an offline discussion, left an inline comment to summarize 👇

[accordeiro]

LGTM! :)