ecosystem/graphql builds against remote master rather than the checkout it lives in

[Toby1009]

Summary

ecosystem/graphql/WORKSPACE:224 pulls this project in over the network:

git_repository(
    name = "com_resdb_nexres",
    branch = "master",
    remote = "https://github.com/apache/incubator-resilientdb.git",
)

The subproject is vendored in the same repository, but depends on its parent as
if it were a separate one. With this default wiring, an ordinary GraphQL build
does not see parent changes until they are merged to master; testing them
earlier requires an explicit local_repository or --override_repository,
which nothing in the tree sets up.

Demonstration

With local modifications present in the checkout, @com_resdb_nexres resolves
to different content than the working tree it sits in:

working tree:
  service/tools/kv/api_tools/kv_service_tools.cpp:129   int c;
  repositories.bzl:75    strip_prefix = "abseil-cpp-20240722.2"

what ecosystem/graphql resolves @com_resdb_nexres to:
  service/tools/kv/api_tools/kv_service_tools.cpp:127   char c;
  repositories.bzl:59    strip_prefix = "abseil-cpp-20211102.0"

Both listings are from the same container in the same run. The second is
whatever master happens to be at fetch time.

Why it matters

With the default wiring, an ordinary GraphQL build does not exercise parent
changes before they are merged. A change that builds and passes everywhere in
this repository can still break GraphQL, and seeing that beforehand requires an
explicit local_repository or --override_repository, which nothing in the
tree sets up.

Note that this does not by itself hold GraphQL on the old Abseil: that
workspace declares com_google_absl 20211102.0 itself at
ecosystem/graphql/WORKSPACE:135 (line numbers as of master at the time of
writing), and because the parent registers Abseil through maybe(...) an
already-declared repository is not replaced. Re-fetching remote master updates
the parent's own sources and BUILD files, not GraphQL's dependency pins.

The effect is that the subproject lives in this tree but integrates like an
external one: changes here and changes there only meet after a merge and a
re-fetch.

Two related observations in the same file

No .bazelversion or MODULE.bazel. Since ecosystem/graphql has its own
WORKSPACE, Bazelisk treats it as the workspace root and finds no version
file, so it falls back to the latest Bazel:

bazelisk in the project root:      bazel 6.0.0
bazelisk in ecosystem/graphql:     bazel 9.2.0

Bazel 9 no longer reads WORKSPACE, so under it nothing in that file is
visible at all:

ERROR: No repository visible as '@com_resdb_nexres' from main repository

Forcing USE_BAZEL_VERSION=6.0.0 is what made the demonstration above
possible. The root .bazelversion is not inherited because Bazelisk stops at
the nearest workspace root.

Dependencies without integrity checks. hedron_compile_commands,
com_google_protobuf (a git_repository on a mutable tag), com_google_absl,
com_github_nelhage_rules_boost, pybind11_bazel and com_resdb_nexres
itself all lack a sha256, and the Abseil pin is the 20211102.0 that does not
compile with GCC 13+.

Not claimed here

I did not establish whether ecosystem/graphql builds successfully today. The
fetch I used to produce the listing above also reported
@com_google_leveldb ... is not defined, but I asked for
@com_resdb_nexres//service/kv:kv_service, which may simply not be a target
this subproject builds. That part needs someone who knows the intended entry
points.

Possible direction

local_repository(name = "com_resdb_nexres", path = "../..") would make the
dependency point at the checkout, so changes are testable before merge. Whether
that is right depends on how the subproject is meant to be released and
consumed, which is a decision for the maintainers rather than something to
change from outside.

Found while working on #245.