[uss_qualifier] rename and extend VerticesResource, rely on it in PlanningAreaResource

[Shastick]

As noted in this comment, VerticesResource and PlanningAreaResource are very similar.

The only difference is that a PlanningAreaResource has an optional lower and upper bounds.

It would make sense to merge them together (possibly dropping VerticesResources and only keeping PlanningAreaResource).

Forward

After discussing, it would make sense to generalize (and rename) VerticesResources so it may hold a 4DVolume (with all fields making it a 3D or 4D volume optional so we may still encode altitude-free areas without time bounds).

For the start an end-time we will need a resolution mechanism similar to other resources that allow users to specify "scenario start time", "scenario start time + 5 minutes", etc. Note the time-bounds support is not the first priority, we can add those in a second step.

Once this resource is created, we can include it in PlanningAreaResource, and look at which other similar resources we might want to create

Notes

changes to configuration that involve renaming or removing resources are usually breaking, and a user-friendly approach should be adopted (ie, first deprecating for a while before actually removing the old resource)

• 4DVolumeResource: [uss_qualifier] rename and generalize VerticesResource to VolumeResource #1138
• integrate into PlanningAreaResource [uss_qualifier] migrate planning_area_resource to new volume resource #1192
• integrate into resources.netrid.ServiceAreaResource [uss_qualifier] migrate service_area to new volume resource #1214
• review all usages and migrate the relevant ones to use the dyamic time-bounds [uss_qualifier] safe usage of planning_area's volume resolution #1248

[Shastick]

From the discussion on #1120, this issue becomes more about finding the proper naming and wrapping a generic vertices or area resource into more specific resources for ISAs, planning areas, etc. Will discuss at today's meeting.