support normalization of caveat context data

[vroldanbet]

Problem Statement

This is the result of this GitHub discussion, but also capturing feedback from some of our customers.

Certain certain context attributes need to be used in multiple relationships. One good example is when attributes are properties of the resource or the subject itself like those similar to an entitlements system to grant employees access to company resources. However, a subject or resource may be present in the relation graph multiple times, or various paths of the graph may leverage the same set of attributes. This leads to a problem: client applications are forced to denormalize the same caveat context data in different relationships.

This adds overhead to the writes and is wasteful on the storage, but importantly sometimes it may be downright not possible, as the client application now needs to keep track of all the places in the schema where this needs to be updated, which leads to potential security issues. The places that need to be updated may also cross organizational boundaries of engineering teams interoperating over the same SpiceDB schema and so they may not even have access to this data.

Solution Brainstorm

As part of GitHub discussion the idea of an entity-specific context storage was brought up. This allows users to associate an object_type/object_id pair with some caveat context data, denoting properties of the node in the graph rather than the edge in the graph. This could be generalized into a key/value store, but that makes it more difficult to optimize how it's loaded, as loading it as part of the relationship could be done in a single roundtrip by keying it by the relationship data - a generic k/v means arbitrary keys that are only known on CEL evaluation time (or using static analysis).

This certainly would require new CRUD APIs, and it should be possible to do the writes atomically with relationship updates, which means updating WriteRelationships API.

I don't have a good picture of what could be done for caching, but I'd imagine the k/v entry would have certainly revisioned and we could either resolve the caveat as soon as possible, potentially resolving the expression earlier or bind the variable values into the expression and caching that as part of the subproblem.