Storage: Reworked storage and garbage collection

The improved GC implementation uses refactored storage
classes instead of directly accessing "unknown" file paths.
The required storage class refactoring is quite substantial
and outlined in the following paragraphs.

The module `buildtool/file_system` was extended by:

- `ObjectCAS`: a plain CAS implementation for
  reading/writing blobs and computing digests for a given
  `ObjectType`. Depending on that type, files written to the
  file system may have different properties (e.g., the x-bit
  set) or the digest may be computed differently (e.g., tree
  digests in non-compatible mode).

A new module `buildtool/storage` was introduced containing:

- `LocalCAS`: provides a common interface for the "logical
  CAS", which internally combines three `ObjectCAS`s, one
  for each `ObjectType` (file, executable, tree).

- `LocalAC`: implements the action cache, which needs the
  `LocalCAS` for storing cache values.

- `TargetCache`: implements the high-level target cache,
  which also needs the `LocalCAS` for storing cache values.

- `LocalStorage`: combines the storage classes `LocalCAS`,
  `LocalAC`, and `TargetCache`. Those are initialized with
  settings from `StorageConfig`, such as the build root base
  path or number of generations for the garbage collector.
  `LocalStorage` is templated with a Boolean parameter
  `kDoGlobalUplink`, which indicates that, on every
  read/write access, the garbage collector should be used
  for uplinking across all generations (global).

- `GarbageCollector`: responsible for garbage collection and
  the global uplinking across all generations. To do so, it
  employs instances of `LocalStorage` with `kDoGlobalUplink`
  set to false, in order to avoid endless recursion. The
  actual (local) uplinking within two single generations is
  performed by the corresponding storage class (e.g.,
  `TargetCache` implements uplinking of target cache entries
  between two target cache generations etc.). Thereby, the
  actual knowledge how data should be uplinked is
  implemented by the instance that is responsible for
  creating the data in the first place.

1 files changed, 2 insertions, 2 deletions

diff --git a/src/buildtool/execution_api/execution_service/execution_server.hpp b/src/buildtool/execution_api/execution_service/execution_server.hpp
index 65ace208..6d99fb6a 100644
--- a/src/buildtool/execution_api/execution_service/execution_server.hpp
+++ b/src/buildtool/execution_api/execution_service/execution_server.hpp
@@ -18,8 +18,8 @@
 #include "build/bazel/remote/execution/v2/remote_execution.grpc.pb.h"
 #include "src/buildtool/common/bazel_types.hpp"
 #include "src/buildtool/execution_api/local/local_api.hpp"
-#include "src/buildtool/execution_api/local/local_storage.hpp"
 #include "src/buildtool/logging/logger.hpp"
+#include "src/buildtool/storage/storage.hpp"
 
 class ExecutionServiceImpl final : public bazel_re::Execution::Service {
   public:
@@ -107,7 +107,7 @@ class ExecutionServiceImpl final : public bazel_re::Execution::Service {
         -> ::grpc::Status override;
 
   private:
-    LocalStorage storage_{};
+    gsl::not_null<Storage const*> storage_ = &Storage::Instance();
     IExecutionApi::Ptr api_{new LocalApi()};
     Logger logger_{"execution-service"};