[rid] observation interface: add metadata

[barroco]

This PR adds additional metadata to the observation harness required to validate the Display Provider capability of the U-Space network identification test suite:

• operator.id
• operator.location
• operator.altitude
• uas.id
• timestamp
• track
• speed
• height
• operational_status

To limit redundant types, a commons.yaml is introduced in the folder to mutualize schema definition between injection and observation.

@BenjaminPelletier may I kindly ask you to have a particular attention at the following points:

• Changes to the observed position altitude description which now requires a minimum resolution of 1 meter. I thought it was acceptable.
• Usage of simple $ref / anyOf. The logic was that simple $ref are used for simple types and anyOf is used when the reference is an object definition. Please let me know if my understanding is not correct.

Please feel free to suggest any improvement on how to generalize the observation interface.

[BenjaminPelletier]

Changes to the observed position altitude description which now requires a minimum resolution of 1 meter. I thought it was acceptable.

Note added -- I think we want to move away from F3411 requirements & language rather than toward.

Usage of simple $ref / anyOf. The logic was that simple $ref are used for simple types and anyOf is used when the reference is an object definition. Please let me know if my understanding is not correct.

Yes, that's my general practice. $ref just replaces all content and in the version of OpenAPI we're using, no siblings are allowed next to $ref, including description. An obvious use of $ref is to define a type once and reuse it, but the description for each field in which that type is used is going to be different. The way to resolve this problem in OpenAPI 3.0.x is to use allOf -- that's the only reason to use allOf. In newer versions of OpenAPI, description is allowed as a sibling of $ref, but that newer version of OpenAPI is not yet widely supported.

[BenjaminPelletier]

I think we want to transition away from language that's specifically aligned with ASTM standard text -- for instance, the USS should provide whatever altitude they know without regard to resolution. When we perform ASTM F3411 tests, we'll check whether the minimum resolution requirement is met, but that might not be a requirement in other RID regimes. For that reason, I think I actually like the old description better ("An altitude, in meters, above the WGS84 ellipsoid.") Also, we don't want to mention "aircraft" since it's use in OperatorAltitude also.

[barroco]

Makes sense. I reverted to the old description.

[BenjaminPelletier]

This LGTM. Following this merge, the next step would be to update the submodule pointer in uas_standards and reautogenerate the code. Then, after that PR is approved and merged, we can make a new uas_standards release. Then, after that release, we can rev the uas_standards version in monitoring and start making use of the API changes.