Add config flag to further disable transition effects caused by bazel pre-5.0 support

[bduffany]

(DRAFT -- looking for feedback)

This is an attempt to address an issue that even when setting --@io_bazel_rules_docker//transitions:enable=no, we still get some config differences across targets built as a docker image dep, and targets not built as a docker image dep. This appears to be caused by this support for Bazel pre-5.0.

Looking for some initial feedback as to whether this approach seems reasonable -- if so, I can add tests and open for review.

Context: https://bazelbuild.slack.com/archives/CA3NW13MH/p1654287739299629

Even more context: we build our app twice (once for pushing to GCS, and once just to get the SHA256 digest of the app so that we know where to find it in GCS), and these path differences due to the config transition are causing the app SHA to mismatch, since we have some path references in some of the app's contents.

---

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• [x] Bugfix
• [ ] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [ ] Documentation content changes
• [ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

Other information

[bduffany]

@laurynaslubys @uhthomas Wondering if either of you have any thoughts on this PR? (The description includes some context)

[uhthomas]

There is a native.bazel_version which could be used instead.

Really though, I would recommend upgrading to the latest version of Bazel. Is there anything preventing you from doing so?

[bduffany]

@laurynaslubys that's understandable. Are there any plans for rules_docker to drop pre-5.0 support in the near-term future?

If not, I'm open to other ideas -- it would be nice to find some workaround that doesn't require a patch. For other folks using this flag, it'd be nice if the transition effects could be fully disabled so that builds both as a docker dep or not can be built in the same configuration (which has implications for caching, checksums, etc.)

@uhthomas It looks as though native.bazel_version only works in a repository context (issue). Also, I am on the latest version of Bazel -- the problem is that this code which is intended to support earlier versions of Bazel is causing a configuration difference (the output directory becomes bazel-out-ST-{HASH} instead of bazel-out).

[github-actions[bot]]

This Pull Request has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!

[github-actions[bot]]

This PR was automatically closed because it went 30 days without a reply since it was labeled "Can Close?"