envoy: removes go dependency

[codefromthecrypt]

According to @lizan #83413 (comment)

Envoy build process pulls Go 1.15.5 by Bazel (https://github.com/envoyproxy/envoy/blob/main/bazel/dependency_imports.bzl#L14), so it isn't relevant to system Go. M1 support should be ignored until Envoy supports that.

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[SMillerDev]

I think we're going the wrong direction here. We do not want software to pull in their own software to build with. At best that violates https://docs.brew.sh/Acceptable-Formulae#stuff-that-requires-vendored-versions-of-homebrew-formulae and at worst it's https://docs.brew.sh/Acceptable-Formulae#we-dont-like-install-scripts-that-download-unversioned-things

[codefromthecrypt]

@SMillerDev so this change is trying to make it more honest than before as even if we depended on system go, as far as I know it was never used. Maybe you can mention impact on this issue as I'm not sure if any Envoy maintainers are reading this one envoyproxy/envoy#17886

[carlocab]

This was already pulling it its own version of Go I think. The only thing this PR does is makes sure we don't have to spend an extra 8~ hours building envoy in Go PRs, which is good for our CI throughput.

[cho-m]

envoy is another Bazel-built formula, so it shares some aspects with other Bazel formulae that don't exactly align with Homebrew's preferences. Specifically, due to Bazel's ideology of reproducible builds, it will vendor various dependences and it will also evade our superenv/shims.

So, unless the upstream specifically provides a way around this, we probably have no easy way to provide our own system libraries, build tools, etc.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[carlocab]

In favour of merging this -- this doesn't change anything about how envoy is built, and saves us a lot of time in CI.

[BrewTestBot]

🤖 A scheduled task has triggered a merge.

[codefromthecrypt]

envoy's internal management of go SDK during build caused another problem, though I highly doubt they will stop doing this #86755 (comment)