rvps: add reference value uuid

[fitzthum]

We use names to identify reference values, but this doesn't capture a particular instance of a reference value. For example, a reference value name might be "firmware_hash", but there could be many reference values with this name. Even if the name is more specific (i.e. includes a version) this is still capturing the target context of the reference value (as in what it represents in the TCB) rather than the source instance.

As such, let's introduce an rv id to uniquely identify an rv instance. To begin with, this doesn't really do anything, but in the future we can generate reference value reports that capture exactly which rv instances were used to validate a guest.

To support backwards compatibility, create a new UUID when deserializing an RV that doesn't have one. Still, update the RV version.

[Xynnn007]

Nice catch to the problem. The name field works the same way as an identifier. My original idea is to use a URI like format to replace name field. I have implemented in this way in the PR deeply in the code.

The idea came from the following materials

1. @thomas-fossati 's example and you once mentioned with a similar format here
2. In more older time, the idea of Target Environment ID (TE ID) here and here

Anyway, I think we can define a URI format to index a reference value, using path separators to semantically distinguish scopes. Furthermore, we can define a specific URI naming convention for CoCo and then unify the entire reference value publishing process.

And this PR will be the first important step on our road to final shape I believe.

[fitzthum]

Yes, I think we should use a URI, but we probably also want a UUID. The URI will represent the target context of the reference value (i.e. what does the reference value represent in the TCB), but the UUID keeps track of a particular RV instance.

Imagine a flow where an admin uploads some RVs, a guest is validated, and then the RVs expire and are updated. The URI has no way to distinguish between these old and new RVs, but the UUID would.

I picture the attestation token having a reference value section that contains URI and UUID pairs for each RV. With this information a user can query the RVPS for information about a particular reference value instance, such as who provided the value, whether it has expired, and the literal value. We would never delete any of these old values (just mark them as expired or replaced) so the RVPS would have a full history of every RV instance it had used.

Anyway there are a few moving pieces here. I'm not in a rush to get this particular feature in. Just wanted to put up a PR before I forget about it.

[Xynnn007]

Yes. A URI+UUID an be simply concat-ed into URI/UUID or URI:UUID. The whole can be treated as a new format URI also