Bzlmod: nodep deps

[Wyverald]

This PR implements the "nodep" edges from https://docs.google.com/document/d/1JsfbH9kdMe3dyOY-IR8SUakS541A7OM8pQcKpxTRMRs/edit?tab=t.0, using the syntax of bazel_dep(..., repo_name=None). The behavior is that these edges are "unfulfilled" unless the module they refer to already exist in the dep graph by some other means.

Most of the changes are in the Discovery class -- I reorganized the code in there to hopefully help with readability, given the new multi-round discovery logic.

Also changed ModuleFileValue.Key to no longer take the applicable override next to the module key -- ModuleFileFunction now gets the root module from Skyframe itself and looks up the correct override. The old setup was always weird (what does it mean to request [email protected] with an incorrect override??).

Beyond that, I changed ModuleFileValue implementations to become records. Just for the heck of it.

Work towards #25214

[Wyverald]

oops... self reminder to write more here

[meteorcloudy]

Nice!

[meteorcloudy]

How does it interact with dev_dependency = True, should we add some test cases?

[fmeum]

The implementation looks good to me, but I wonder whether we could further minimize the impact of nodeps (assuming that there will be many, see boost). As it is, Bazel would still need to download and parse the module files of all nodeps modules some version of which is contained in the dep graph.

If we didn't have compatibility_level, we wouldn't have to fetch nodeps whose version compares less or equal to a module version that's already in the dep graph, knowing that they couldn't possibly become relevant. Maybe we can relax the handling of nodeps somewhat to still get this behavior? For example, we could specify that A with a nodep on B 1.0 (compatibility level 1) and B with a regular dep on B 2.0 (compatibility level 2) would not result in a build failure, but rather select B 2.0.

I am bringing this up now since changing it later would be a breaking change.

[fmeum]

Could you add a test for a fulfilled no-dep that crosses a compat level boundary (and thus causes the build to fail)?

[Wyverald]

For example, we could specify that A with a nodep on B 1.0 (compatibility level 1) and B with a regular dep on B 2.0 (compatibility level 2) would not result in a build failure, but rather select B 2.0.

That's already the case IIUC -- the A->B1.0 edge is not examined during selection, so we never notice the existence of B1.0. (It's the same as the A-regular->B1.0 and B-nodep->B2.0 case)

[fmeum]

I see. In that case, how about making it so that we don't even fetch the module file of B1.0 during discovery? In any case, could you add assertions on the registry files fetched during discovery to the unit tests?