feature: Need to make an Architectural choice to decide, whether to define Store Policy and expose it to consumers

[yogeshbdeshpande]

Need: Endorsements are of different nature, Integrity or Integrity and Privacy Protected, hence each type of Endorsement may need a different protection, Hence the need for different type of stores. This requires a Policy to be defined.

[yogeshbdeshpande]

Policy layer has a bearing on the API defined in the vts.proto.

Should we have a single API AddEndorsementRequest() where the policy is negotiated upfront?

See also issue veraison/veraison#151

[yogeshbdeshpande]

Notes from @setrofim

Different security requirements for different types of endorsements do not necessitate different stores -- as long as the one store meets the union of these requirements.

A particular setup may benefit from (or even require) multiple stores, so we should definitely allow a multi-store configurations, however there is no need to mandate it (let alone mandate specific kinds of stores). Setting up multiple stores increases the complexity of deployments. We should not require this complexity for deployments that don't need them.

We do need to establish a store configuration four our "default"/"standard" Veraison configuration (our current situation of a trust anchor store and other endorsements store seems reasonable), but we should not require it by having it explicitly reflected in the APIs.