[scd] extent with unbounded start/end can lead to invalid entities

[RustedBones]

Describe the bug

When submitting an entity with combination of unbounded extent, the entity is not rejected and does not consider unbounded cases.

To Reproduce

create a new constraint or op-intent reference with

• extent containing a full unbounded volume

{"extents": [{"time_start": "xxx", "time_end": "xxx"}, {}]

• extends containing partially unbounded volumes

{"extents": [{"time_start": "xxx"}, {"time_end": "xxx"}]

The resulting entity will have time_start and time_end as time bounds instead of being unbounded

Expected behavior

entity time bounds should containt all volumes

[mickmis]

Expected behavior
entity time bounds should containt all volumes

Reading the OpenAPI definitions for PutOperationalIntentReferenceParameters.properties.extents.description:

            Spacetime extents that bound this operational intent.

            Start and end times, as well as lower and upper altitudes, are
            required for each volume. The end time may not be in the past. All
            volumes, both nominal and off-nominal, must be encompassed in these
            extents. However, these extents do not need to match the precise
            volumes of the operational intent; a single bounding extent may be
            provided instead, for instance.

I think that the expected behavior for operational intents would be to return a 400 if any time bound is missing from the request, rather than assuming that the time bounds of some volumes apply to the ones that don't exist.

For constraints we have in PutConstraintReferenceParameters.properties.extents.description:

            Spacetime extents that bound this constraint.

            The end time may not be in the past.

            All volumes of the constraint must be encompassed in these extents.
            However, these extents do not need to match the precise volumes of
            the constraint; a single bounding extent may be provided instead,
            for instance.

It is less explicit but IMO that implies it is the same than for operational intent: a 400 should be returned from the endpoint, rather than assuming time bounds.

WDYT?