Add function to Store API to get the inner store when possible

[allada]

Adds inner_store() function to all stores that enables the resolution of inner stores recursively to get an underlying store. This is mostly for places that can perform optimizations when specific code paths can be optimized with specific stores.

towards: #409

---

This change is 

[allada]

+@aaronmondal

Reviewable status: 0 of 22 files reviewed, all discussions resolved (waiting on @aaronmondal)

[aaronmondal]

I'm not sure whether this is an API that should apply "globally" to all stores. I also find it somewhat confusing that e.g. the FastSlowStore's inner_store is itself and not e.g. a vector of its fast and slow stores or something like that.

Actually this is something that's been bothering me for a while: In my mind something like the RedisStore and the DedupStore are quite different. The former actually stores data while the latter is just a wrapper. Our current API doesn't reflect that and I think it could make things like an inner_store functionality more intuitive if we split up stores into e.g. "stores" and "store-wrappers". This way it'd be clear that a store can't have an inner store (i.e. it's always a leaf node), and a store-wrapper always has some inner store (i.e. it's never a leaf node).

This could also simplify the API for non-wrapper stores as those only need to care about how to read/update data.

Reviewable status: 0 of 22 files reviewed, all discussions resolved

[allada]

I partially agree. In the case of DedupStore, there is no actual inner store, the inner store is itself. What I'm trying to do is create a case where inner_store will resolve any stores that pass through the data but do no complex logic on it. This will allow us to use things like:

    "GRPC_CAS_STORE": {
      "size_partitioning": {
        "size": 10000,
        "lower": {
          "grpc": {
            // ...
          }
        },
        "upper": {
          "s3_store": {
            // ...
          }
        }
      }
    },
    "WORKER_FAST_SLOW_STORE": {
      "fast_slow": {
        "fast": {
          "filesystem": {
            // ...
          }
        },
        "slow": {
          "ref_store": {
            "ref": "CAS_STORE"
          }
        }
      }
    }

This config would allow the GRPC optimizations we have laying around significantly more frequent.

The specific use case that I am doing this for is for #409, what I plan on doing is checking to see if the store I'm uploading to when a worker is uploading it's result is a filesystem store. If it is, it'll simply downcast it to the filesystem store and then move the file directly instead of coping the data. The reason I wanted to do this first is because ref_store is frequently used when the worker lives on the same machine as the CAS.

Reviewable status: 0 of 22 files reviewed, all discussions resolved (waiting on @aaronmondal)

[aaronmondal]

Reviewed 22 of 22 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @allada)

---

cas/store/shard_store.rs line 178 at r1 (raw file):

        };
        let index = self.get_store_index(digest);
        self.weights_and_stores[index].1.clone().inner_store(Some(digest))

nit: Might be worth considering some sort of struct to get rid of the 1 syntax here. Not too relevant though.

[MarcusSorealheis]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @allada)

[allada]

Reviewable status: 0 of 43 files reviewed, all discussions resolved (waiting on @aaronmondal)

---

cas/store/shard_store.rs line 178 at r1 (raw file):

Previously, aaronmondal (Aaron Siddhartha Mondal) wrote…

nit: Might be worth considering some sort of struct to get rid of the 1 syntax here. Not too relevant though.

Kinda agree, but not for this PR.