feat(readfallback): allow disabling FindMissing replication

[joeljeske]

Summary

Add disableFindMissingReplication to the shared readFallback configuration. When true, FindMissingBlobs() still checks the primary backend and then queries the secondary for digests missing from the primary, but does not replicate blobs found only in the secondary. Replication during Get() and GetFromComposite() is unchanged.

This lets existence checks avoid pulling blobs into the primary before they are actually read. The option is available wherever a readFallback backend is configured, including nested backends.

NewReadFallbackBlobAccess() now takes a pair of replicators: one for Get()/GetFromComposite() and one for FindMissing(). The configuration layer passes the same replicator instance for both by default, so concurrency limits and deduplication remain shared. When disableFindMissingReplication is set, it passes a no-op replicator for FindMissing().

Compatibility

• Use an ordinary proto3 bool, matching existing configuration fields such as disable_http2; presence tracking is unnecessary.
• Omitted and explicit false values retain the existing replication behavior; existing configuration files need no changes.
• NewReadFallbackBlobAccess() gains a second replicator argument. All in-repository callers are updated.
• Regenerate the Go protobuf bindings using the repository's Bazel toolchain.

Testing

• bazel test //pkg/blobstore/... — all 12 test targets passed.
• Mock tests cover the existing behavior with a shared replicator, and that Get(), GetFromComposite() and FindMissing() each use their own replicator when they differ.
• bazel run //:gazelle — no BUILD changes.

Generated with Toshi

[EdSchouten]

Why not change this field into two separate ones:

• get_replicator
• find_missing_replicator

And then you can set the latter to { noop: {} }.

[joeljeske]

Hey @EdSchouten I can make that change but I didn't for 2 reasons:

1. Users that want to replicate both (like today), will now need to configure 2 replicators, which means it will duplicate the concurrency limits between the replicators , and it will prevent deduplication across the replicators from functioning. For some setups using a remote replicator, this may be fine, but others using a local replicator (e.g. with bb_clientd) it can cause duplicate replication.
2. Its not backwards compatible, and users must update their configuration

What do you think? Can we keep it this way, or would you prefer to have separate replicators despite the potential performance impact?

[EdSchouten]

Fair point. Then let's aim for a solution in between:

• Let the BlobAccess take a pair of replicators.
• Let the configuration files use the structure as is.

[EdSchouten]

LGTM! Will merge once I've confirmed CI is happy.