go: support & use aggressive caching

[DomT4]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

I hadn't planned to move on this so quickly but impressively core today had its first Go Module using PR, so this has become more useful than it would've been. Useful reading on the Modules system can be found via https://golang.org/doc/go1.11#modules.

GOCACHE has been a thing for a while but it hasn't really been especially beneficial to us, so I've ignored it, but with the Go Modules system it can be incredibly useful in reducing build times & thus CI burden. A lot of this is explained rather nicely here.

The upsides here for us are obvious:

1. We do a lot of go-based builds, and the more things move over to the module system the more comprehensive that cache will become and we'll need to remotely fetch less dependencies, which massively speeds up build times even on high-speed connections.
2. Module dependencies aren't limited per formula. If hugo fetches a dependency that is the same version as, for example, wiki also needs wiki won't bother to fetch that version remotely but instead will simply pluck it out of the cache.

If we look at hugo, because it's the only formula so far with Module support:

First build: built in 1 minute 41 seconds
Second build: built in 14 seconds.

It's worth noting perhaps that we can use just the module cache rather than the build cache + module cache combination, but doing so leads to a significant reduction in regained build time. A build under that system pops an average build time with hugo (after the first build) of ~70 seconds, which is only a 30 second saving on the first build. However, if we wanted to speed up builds whilst also not eating big chunks of disk space that is an option.

The downside of a build cache + module cache system is disk usage. go does not exactly eat up disk space sparingly, and the cache size from hugo alone is 258.8MB. That could be an issue on CIs where disk space is already a squeeze at times, but it's not much different to how we let the java_cache behave now. The major difference between java_cache and go_cache here I guess is that things that use go are much more regular visitors in the CI system.

All Module-supporting formulae need to do to use the shared cache is instead of deleting the GOPATH env we set everywhere replace it with this:

ENV["GOPATH"] = "#{HOMEBREW_CACHE}/go_cache"

[MikeMcQuaid]

Nice work here @DomT4 👍

[DomT4]

Thanks Mike! I'll try to keep an eye on how much this whacks CI on disk usage and review again if necessary.

There's a follow-up in #4778 to resolve an issue I missed initially, le sigh.