V3 idea: Let the CAS be encrypted + the AC be encrypted/signed

Right now the CAS and the AC are not encrypted and/or signed. This means that systems that store the data have full access to the entire data set. This is bad for confidentiality. Even though the CAS is immutable, the AC can easily be tampered with.

At first glance, it would be trivial to encrypt the CAS: simply apply some symmetrical encryption on top of it and only let clients and workers have access to the key. Unfortunately, this wouldn't allow storage infrastructure to implement GetActionResult() anymore, as ActionResult messages reference Tree objects. GetActionResult() is supposed to touch everything referenced by the Tree. The Tree would need to be decomposed into an encrypted and a non-encrypted portion.

Encrypting the CAS also doesn't allow us to build schedulers that don't have the encryption key, as those need to parse the Action and the Command to be able to extract `do_not_cache` and platform properties to route the request properly.

This is a design discussion with no files or tests named. Start by mapping the CAS, AC, Tree, ActionResult, Action, and Command relationships described in the issue; done would require a design that protects stored data while preserving GetActionResult() and scheduler routing without giving storage infrastructure or schedulers the encryption key.

Written by the indexing model from the issue text.