build: assert minimum bazel version in use

[rickystewart]

Use bazel_skylib's built-in functionality to assert the minimum
supported Bazel version. We could also use .bazelversion to specify an
exact version that must be used, but that seems unnecessarily
restrictive.

v3.5.0 was arbitrarily chosen as being probably "recent enough", but I
did verify that a build does work with that version of Bazel.

Fixes #56059.

Release note: None

[cockroach-teamcity]

This change is 

[irfansharif]

This LGTM, but I still prefer pinning an exact version which something https://github.com/bazelbuild/bazelisk would make easier. I remember @jin suggesting it to us somewhere, and seems like a better thing to do overall. On the plus side, cause bazelisk is written in Go, it'll make our onboarding experience nicer and consistent across the various OS devs use. You'd need Go, go get github.com/bazelbuild/bazelisk, and you're off to the races. Shouldn't hold up this PR, but possibly something to consider when doubling down on the dev experience.

Reviewable status: complete! 0 of 0 LGTMs obtained

[rickystewart]

A concern I have is what happens in CI. If we pin to a specific version then our CI should respect that but we currently have no plan for how we're going to manage those upgrades. i.e., if I update .bazelversion in a PR, then CI needs to be able to handle that and have access to that new version of Bazel. Currently with how we do CI builds on TeamCity, new toolchains require updating the agent image which can't be done atomically. We could use bazelisk in CI to circumvent the issue, but IDK how appropriate it is for production scenarios, and then we'd also have to maintain a fork of the Bazel releases as well. I guess all of that stuff is possible, but that necessitates a lot of design work that I'm not willing to commit to right now. We can easily add that on later if we find that it's valuable, though.

We could add a .bazeliskrc file to tree to support the dev scenario without impacting CI, but then this PR still shouldn't be blocked (the two changes have nothing to do with each other).

[irfansharif]

I agree that none of the above should be gating this PR. I had meant to rubber stamp it earlier, but looks like I didn't. Whoops.

[rickystewart]

bors r+

[craig]

Build succeeded:

• GitHub CI (Cockroach)