Remove bazel-go-ethereum fork, use upstream go-ethereum

[prestonvanloon]

What type of PR is this?

Other

What does this PR do? Why is it needed?

We have been maintaining bazel-go-ethereum for some time. The root cause is that bazel build file generation doesn't understand how to reference c dependencies in subdirectories.

The solution I have implemented here is to commit a few go-ethereum c dependencies into the vendor folder.

• Add github.com/karalabe/usb to vendor directory. Disable all hid functionality.
• Add a patch to the sepc256k1 BUILD file generation

I took a shortcut with the usb library. We don't use this in prysm at all and I was spinning tires trying to figure out the right combination of things to add to the build files.
So, the usb library is stripped to be disabled. This is the same behavior we've done in bazel-go-ethereum.

Which issues(s) does this PR fix?

This unblocks some desired behavior for the merge testing. #9716

Anyone can now drop in a replacement for go-ethereum and it should work without thinking about messy bazel stuff (unless the drop in has new exotic c/c++ deps). Example below.

go mod edit -replace github.com/ethereum/go-ethereum=github.com/MariusVanDerWijden/[email protected]
go mod tidy
bazel run //:gazelle -- update-repos -from_file=go.mod -to_macro=deps.bzl%prysm_deps -prune=true
go mod tidy

Other notes for review

• Bumps go-ethereum to v1.10.10
• Some changes required to the toolchain for cross compile due to some more darwin dependencies upstream

Resolves #5418

[prestonvanloon]

Change to draft. Cross compile is broken on mac, need to test windows.

[prestonvanloon]

Tested cross compiles
✔️ linux_amd64
✔️ linux_arm64
❌ darwin_arm64
✔️ windows_amd64

On darwin

external/com_github_rjeczalik_notify/watcher_fsevents_cgo.go:10:10: fatal error: 'CoreServices/CoreServices.h' file not found
#include <CoreServices/CoreServices.h>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Same issue as rjeczalik/notify#196

[prestonvanloon]

Cross compile fixed.

[nisdas]

For github.com/ethereum/go-ethereum/crypto/sepc256k1, is there anyway we can ensure that whenever we update our geth commit, our vendored dependency is always in sync with that commit ? Otherwise there is the possibility of the the dependency simply being out of date.

[prestonvanloon]

For github.com/ethereum/go-ethereum/crypto/sepc256k1, is there anyway we can ensure that whenever we update our geth commit, our vendored dependency is always in sync with that commit ? Otherwise there is the possibility of the the dependency simply being out of date.

@nisdas I think we should consider applying patches to go_repository. This has been harder to maintain in the past but would be a safer check that sepc256k1 is the same code as upstream. I'll give this a try tomorrow and see how large the patch would be for sepc256k1. The root of the fix was to define a hdrs target and include it in the go_library target so that may not be a very big patch file. I also expect that the c header code will not change, but the go bindings might.

[prestonvanloon]

Still working on this.