Refactor cache to support storing resources in memory

[rosstimothy]

While the current cache storage is also in memory, it leverages the memory backend which requires converting resources to and from json. Marshaling json is suboptimal and is often a source of CPU and memory consumption. The biggest problem with json marshaling though is that it requires calling CheckAndSetDefaults. When validations enforced in CASD become stricter it can leave caches unable to become healthy when there are mixed versions within a cluster as they all might have a slightly different view of what should be allowed.

As a means to solve both problems, this changes the cache to store resources received from the upstream directly in memory without doing any conversion to json. There are two gotchas with this approach, caching is no longer "free" and cloning of resources must be done diligently to avoid races. Historically the cache relied on the storage implementation in services/local to manage persisting resources in the cache's backend.Memory. However, that will no longer be the case as the cache needs to support storage directly in memory. In order to reduce the burden this may pose on developers the new collection machinery is simpler, and helpers will be added on top of sortcache.SortCache to make a second storage implementation trivial.

The changes here are two fold, mark the existing collections machinery as legacy and introduce new machinery to operate entirely in memory. This includes an initial implementation of caching for static tokens, users, and cert authorities that leverages the new collection machinery. Additionally, all of the new resource specific code was moved to lib/cache/static_tokens.go, lib/cache/users.go, and lib/cache/cert_authority.go. This follows the blue print some of the newer cached resources use to make it easier to identify where code for a specific resource lives and to reduce the size of the cache.go and collections.go files.

Once this lands I plan to copy the same pattern used on other cached resource until all of the legacy collections are gone.

[fspmarshall]

nit: SortCache deletes the item across all indexes if it is deleted on any index, so only one call to Delete is required (though maybe just leaving as-is is easier than deciding which one to use lol).

[espadolini]

Does it make sense to have a primary index and secondary, non-unique indices? As it is we're basically requiring the secondary indices to include the "primary key" as a tail all the time anyway.

[fspmarshall]

I considered adding support for non-unique indices when I initially implemented the sortcache. I decided that it was simpler not to bother. It sounds good in theory, but pagination that works across restarts is actually tricky to do with non-unique indices. Appending the primary key makes pagination trivial and preserves the standard sort order within groups of colliding values, which is especially nice when dealing with low cardinality indices such as access request state. Seemed like non-unique indices would be a big headache for little payoff.

[rosstimothy]

These tests were moved unaltered from cache_test.go.

[espadolini]

Does it make sense to have a primary index and secondary, non-unique indices? As it is we're basically requiring the secondary indices to include the "primary key" as a tail all the time anyway.