Simplify remote store load_bytes API

[huonw]

This is an no-functionality-change refactoring of store::remote::ByteStore::load_bytes_with that's arguably cleaner and also step towards #11149. In particular:

1. that method doesn't need to take a closure any more, and thus is refactored to just be the "simplest": load_bytes(...) -> Result<Option<Bytes>, String>
2. that method previously didn't retry, and thus users had to do the retries themselves: this moves the retries to be fully within the load_bytes method itself, which is both easier to use, and keeps implementation details like gRPC (previously exposed as the ByteStoreError::Grpc/tonic::Status error variant) entirely contained to store::remote::ByteStore
3. to emphasise that last point, the ByteStoreError enum can thus become private, because it's an implementation detail of store::remote::ByteStore, no longer exposed in the public API

Step 1 resolves (and removes) a TODO comment. That TODO references #17065, but this patch doesn't fix that issue.

(NB. a significant fraction of the diff is just reindenting after change the nesting level.)

---

Background: this gets closer to #11149 by making it easier to factor out a "provider" trait: store::remote::ByteStore stores an Arc<dyn ByteStoreProvider>, where the ByteStoreProvider trait might be something like the following, implemented for the REAPI gRPC services and also for HTTP backends (as sketched in #17840):

#[async_trait]
pub trait ByteStoreProvider: Sync + Send + 'static {
  async fn store_bytes(&self, digest: Digest, bytes: ByteSource) -> Result<(), String>;
  async fn load_bytes(&self, digest: Digest) -> Result<Option<Bytes>, String>;
  ...
}

This trait needs to avoid generic methods (like the old load_bytes_with), so that it can be used as a dyn trait object.

[stuhood]

Thanks, looks good. My only minor concern is that to resolve #17065, we will need to change this API again to return a stream, and it seems like this is probably as good a time as any to do that? But happy for this just to be a cleanup instead.

[huonw]

Ah, yeah, fair enough. I'll do that as follow up (no guarantee when, though!).

[huonw]

#18054