Align QoS B and QoS B&A with Commonalities r4.4

[Masa8106]

Problem description
In the CAMARA validation for Commonaities r4.4, there was 5 warnings. The details are mentioned in PR#149.

Expected behavior
To correct info.description template 'additional-error-responses' and to remove unused components for alignment with Commonalities r4.4.

Alternative solution
None

Additional context
None

[hdamker]

#154 fixes the validation findings that came with Commonalities r4.4. Aligning with r4.4 (0.9.0) involves more than that; see camaraproject/QualityOnDemand#619 and camaraproject/QoSProfiles#26 for the same alignment in other repos. For qos-booking.yaml the additional points are:

1. x-camara-commonalities: still 0.8.0, should be 0.9.0 (in both API files).
2. Deprecated Generic<status> responses: deprecated as of 0.9.0 and planned for removal in the next cycle (replacement list in code/common/CAMARA_common.yaml). Proposed mapping:
   • Generic401 → Unauthenticated401, Generic403 → PermissionDenied403 (all operations and the callback)
   • Generic400 (getBookingById, deleteBooking, retrieveBookingByDevice, callback) → BadRequest400, or BadRequestWithRange400 where OUT_OF_RANGE applies
   • Generic404 (createBooking, retrieveBookingByDevice) → IdentifierNotFound404: there is no path parameter, and the test definitions already expect only IDENTIFIER_NOT_FOUND
   • local NotFound404 → catalogue NotFound404 (same code set)
   • BookingAlreadyExists409 → AlreadyExists409 (same code set)
   • Generic422 (retrieveBookingByDevice) → DeviceIdentifier422
   • Generic429 → TooManyRequests429, or a local 429 with the shared GENERIC_429_QUOTA_EXCEEDED example if QUOTA_EXCEEDED should stay
   • Generic410 (callback) → SinkGone410 from CAMARA_event_common.yaml
3. Local error responses (CreateBooking400, BookingUnprocessableEntity422): $ref the shared examples from CAMARA_common.yaml / CAMARA_event_common.yaml instead of the inline copies, and keep only the QOS_BOOKING.* examples inline (Design Guide, "Define the error response locally"). CreateBooking400 declares INVALID_TOKEN but has no example; GENERIC_400_INVALID_TOKEN covers it.
4. sink: replace the inline definition in BaseBookingInfo with the common Sink schema from CAMARA_event_common.yaml.
5. To decide: 422 EVENT_NOTIFICATIONS_NOT_SUPPORTED for createBooking with sink (Event Subscription and Notification Guide, "Sink delivery behaviour"). If implementations without notification delivery are allowed, add the code to BookingUnprocessableEntity422 (shared example available). As an initial (0.x) version, this does not require a major version.
6. Test definitions:
   • qos-booking-createBooking.feature line 472 ("Booking in conflict") expects CONFLICT, but the spec declares only ALREADY_EXISTS for 409, and CONFLICT is deprecated. It should expect ALREADY_EXISTS.
   • Change OAS pointers from /components/... to the #/components/... form used by the r4.4 test templates (still /components/... in createBooking, deleteBooking, retrieveBookingByDevice).

Not applicable: the new common SingleIpv4Address / SingleIpv6Address, because ApplicationServer accepts subnet masks.

Most of this also applies to qos-booking-and-assignment.yaml. Since #139 is reworking that file, a follow-up after #139 is merged seems simpler.

Suggestion: add points 1–6 to #154, or handle them in a separate PR after #154. #153 touches the same components area, so whichever lands second needs a rebase. @Masa8106, what do you prefer?

[Masa8106]

@hdamker, thank you for your comment.
Regarding the suggestion from you, I prefer handling points 1-6 in a separate PR. (Basically I would like to resolve one by one.)
On #153, I will try to rebase it after merging #154.

[hdamker]

On #153, I will try to rebase it after merging #154.

@Masa8106 You can just ping me to do it - should be anyway no problem. Most probably I will notice when #154 is merged.