Allow nogo to depend on go_library

[thomas-wk]

This is a limited version of a previous PR that added a config transition to
the nogo rule that enabled it to build itself without depending on itself.

Unfortunately that PR had to be rolled back because of complexities around
host configuration. Host configuration is terminal (specifically user defined
transitions are skipped) and therefore the transition in the nogo rule that
avoids dependency cycles was skipped. This prevented all host mode tools from
building.

This PR works around host mode limitations via using a config_setting with a
default value of noop nogo. [Making host mode buildable - although without nogo].
This config_setting is controlled via 2 boolean settings - 1 indicating that
we are currently bootstrapping nogo (and therefore cannot depend on it) and
another indicating that we are requesting the nogo binary thru go_context_data rule
to execute a build. This allows target, exec and other non-hostmode configs
to use nogo (as long as we're not bootstrapping nogo).

This PR replaces go_tool_librarys in org_golang_x_tools with aliases to the
go_default_library. go_tool_library cannot be removed 100% because it is used
by other parts of go_rules (eg: coverdata) to avoid circular deps.

The original reverted PR added the capabilities to define nogo via a label_flag - and had some more extensive cleanup of the go_rules repo. PLMK how you'd like to proceed.

What type of PR is this?

Feature

What does this PR do? Why is it needed?

Creating parallel build graphs of go_tool_library inhibits the usability and extension of nogo. It is a great tool - this makes it easier to extend.

Which issues(s) does this PR fix?

Fixes #2374

Other notes for review

[google-cla]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[thomas-wk-cb]

@googlebot I consent.

[robfig]

Thank you for the PR, and I apologize for the length of time it's taken to review.

I just tested this using this simple repo which pulls in staticcheck using nogo:
https://github.com/robfig/staticcheck-nogo-example

It works as expected. This is great! This unlocks staticcheck usage for Bazel repos, which we were wanting but didn't have before.

The code looks fine to me, but I am not very knowledgeable about this area so would like someone else in @bazelbuild/go-maintainers to sign off as well.

[robfig]

To confirm, these patches can't be deleted entirely because they are needed to bootstrap Gazelle, even though Gazelle now likely creates correct BUILD files now without go_tool_library?

[thomas-wk]

Yeah gazelle's default build file generation logic works fine now with nogo; so the segments of the patch where I replaced the go_tool_library targets with aliases are not strictly needed.

I left aliases to avoid any breakages in folks nogo rules at upgrade time (eg - rules_go's documentation has examples depending directly on these targets - so I assume folks have copied them into their repo's setup).

This patch file is a beast and has a lot of BUILD definitions that have nothing to do with go_tool_library or nogo, so I'm unsure if it can be entirely deleted.

[robfig]

@linzhp also tested this PR on the Uber Go repo and found it worked as expected, so we feel pretty good about this. Thanks again!

We should also remove go_tool_library documentation from go/core.rst.. do you mind adding that to the PR?

[thomas-wk]

@linzhp also tested this PR on the Uber Go repo and found it worked as expected, so we feel pretty good about this. Thanks again!

We should also remove go_tool_library documentation from go/core.rst.. do you mind adding that to the PR?

done

[robfig]

Closing and reopening to re-run buildkite

[robfig]

The build failure can't possibly be related, but I don't yet have permission to re-run, so I will merge over the BuildKite complaint. Thank you!