revert: revert: Use patch from @bazel_tools//tools/build_defs/repo

[tyler-french]

What type of PR is this?

Bug fix

What package or component does this PR mostly affect?

go_repository

What does this PR do? Why is it needed?

This diff reverts #1277, which reverted #1269

This diff uses Bazel's implementation of patch rather than the system, making it hermetic.

The main issues described in #1277 no longer exist:

It seems like by using the native repository_ctx.path(file, strip)
in bazel_tools, we would be applying the patches to the repository
archive before BUILD file generation. This is not desirable as
patches on top of go_repository are often used to modify the BUILD files
themselves.

The patch is always called after build file generation: https://github.com/bazelbuild/bazel-gazelle/blob/05f5493ca9b74f037dde928721dc01ffaa6de1a2/internal/go_repository.bzl#L282-L293

Another difference is that patch allows patch files without trailing
blank/empty lines while repository_ctx.patch() would fail to recognize
EOF in patch files without a trailing empty line:

This also appears to be fixed. However, this is extremely minor, and there should be very few affected cases here.

One note, is that repository_ctx.patch() is a bit more strict, and usually requires more "recent" patches with accurate line numbers.

Which issues(s) does this PR fix?

Fixes #1380

[linzhp]

@sluongng Can you take a look? We tested it with several go_repository rules used by Uber that requires patching BUILD.bazel files, they all worked

[sluongng]

Unfortunately, I don't have a repo to test this with right now.

But iirc, the problem was not with the ordering of the patch() call after BUILD file generation. The problem was patch was being run over a fresh copy of the downloaded archived, not the copy with BUILD file generated within.

So I don't think the PR description properly addressed what was changed and fixed the issue.
I wonder if the bzlmod activities that @meteorcloudy and @fmeum implemented recently accidentally fixed this.

If that's the case, I suspect we should be able to bisect this somehow to find the fixed commit.
It's could be important to let our users know about Bazel version incompatibility with rules_go around this change.

---

The change itself looks good to me.

[meteorcloudy]

I wonder if the bzlmod activities that @meteorcloudy and @fmeum implemented recently accidentally fixed this.

Did you mean this commit: bazelbuild/bazel@e9a4e93? But I don't see how it changed where the patch was executed. So probably not?

[tyler-french]

But iirc, the problem was not with the ordering of the patch() call after the BUILD file generation. The problem was patch was being run over a fresh copy of the downloaded archived, not the copy with the BUILD file generated within.

Maybe our behavior is different, but for us, the patches are properly applied to $(bazel info output_base)/external. In many cases, the patches are applied to BUILD.bazel files that do not exist in the open source version and are generated by gazelle.

This is probably worth confirming.

[linzhp]

The problem was patch was being run over a fresh copy of the downloaded archived, not the copy with BUILD file generated within.

We don't see a way to reproduce this issue, so I am going to merge this for now. Feel free to create an issue with an example repo if it persists.

[dpoluyanov]

It hits us too, so I've created an repro repository https://github.com/dpoluyanov/bazel-gazelle-gh-1381 and a new issue: #1424