[swartzn]

What does this PR do / why do we need it?

Remote and Sync never checked their gRPC callers. Any host that could reach them could manage jobs
and RSTs, or make Sync, which skips file permission checks, read or write any file in BeeGFS.
Remote also sent its raw auth secret to every Sync node.

Both servers now require the connection authentication hash from every caller when the BeeGFS
client of their mount uses connection authentication. Each service reads the client's
connDisableAuthentication and connAuthFile from /proc/fs/beegfs. If it cannot read them, it
refuses to start unless the optional [auth] section, with auth-file or auth-disable, says what
to do. No setting can turn the check off while the client can be read.

• Remote no longer sends the secret to Sync. Each node reads its own file and sends only the hash.
• Remote's management.auth-file and management.auth-disable are deprecated and ignored.
• beegfs-watch sends the hash only to subscribers that set grpc-send-auth-secret.

We gain authenticated Remote and Sync endpoints, and the raw secret no longer leaves a host. We
lose mixed-version operation: Remote, Sync and Watch must be upgraded together.

Related Issue(s)

https://github.com/ThinkParQ/beegfs-core/issues/4813

Where should the reviewer(s) start reviewing this?

1. rst/internal/connauth/connauth.go: the package comment states the rules, and resolve applies them.
2. common/beegfs/beegrpc/auth.go: AuthServerOptions, the server-side check.
3. rst/remote/cmd/beegfs-remote/main.go and rst/sync/cmd/beegfs-sync/main.go: where each
   service resolves its state and wires it into its server, CTL and outgoing calls.
4. rst/remote/internal/worker/beesync.go and rst/sync/internal/beeremote/grpc.go: how Remote
   and Sync authenticate to each other.
5. watch/internal/subscriber/: the grpc-send-auth-secret opt-in.

Are there any specific topics we should discuss before merging?

• Containers. A container running Remote or Sync must be able to read /proc/fs/beegfs, and
  the auth file at the path the client reports. Otherwise [auth] must be set. Mounting the client
  inside the container meets both requirements.
• Old clients. A client that does not report connDisableAuthentication counts as unreadable,
  so it also needs [auth]. We have not checked which client version added the key.
• Watch upgrade. An existing Watch subscriber entry for Remote must add
  grpc-send-auth-secret = true. Without it, events stop reaching Remote once Remote checks, and
  nothing fails at startup.
• Scope of the check. It proves membership of the file system, not admin rights. Every host
  that holds the secret can still use the full Remote API.

What are the next steps after this PR?

• Deprecate the unused auth_secret and auth_disable fields in flex.proto.
• Release notes: the lockstep upgrade, the Watch opt-in, the deprecated management.auth-*
  settings, and the container requirements.

Checklist before merging:

• Documentation:
  • Developer documentation: code comments and the shipped TOML files are updated.
  • User documentation: still needs the items listed under next steps.
• Testing:
  • Unit tests added for the client and [auth] rules, decoding of unset [auth] keys, the
    server check, and authentication between Remote and Sync.
  • Integration testing: not yet run on a cluster with connection authentication.
• Git Hygiene:
  • Do commits adhere to Conventional Commits?
  • Is the commit history squashed down reasonably?

🤖 Generated with Claude Code