Align QoS B&A with Commonalities r4.4

[gmuratk]

What type of PR is this?

Add one of the following kinds:

• enhancement/feature
• repository management
• tests

What this PR does / why we need it:

To align QoS B&A with Commonalities r4.4

Which issue(s) this PR fixes:

Fixes # partially #151

Special notes for reviewers:

@Masa8106 there were few decisions made that are not specifically called out by Issue #151. I tried to capture these in the ChangeLog with pre-fix to each change listed. Items with DECISION and ENHANCEMENT pre-fix don't really bring in any functionality but they are mostly cleanup and applying the Design and Notification Guidelines.

As for the test definitions, previous single feature file was removed and replaced by 7 per operation feature files.

Changelog input

 release-note
Legend:
- `[ISSUE_151]` is requested in the description of issue #151.
- `[COMMONALITIES_R4.4]` is required or implied by the Commonalities r4.4 (0.9.0) documents, but is not stated in the issue.
- `[DECISION]` and `[ENHANCEMENT]` was identified during the review and is not required by the issue or by Commonalities.

### Changed
- [ISSUE_151] `x-camara-commonalities` updated from `0.8.0` to `0.9.0`.
- [ISSUE_151][COMMONALITIES_R4.4] Deprecated `Generic<status>` error responses replaced by the catalogue responses of `CAMARA_common.yaml` and `CAMARA_event_common.yaml`:
  `Unauthenticated401`, `PermissionDenied403`, `BadRequest400`, `NotFound404`, `AlreadyExists409`, `DeviceIdentifier422`, `TooManyRequests429` and, in the notification callbacks, `SinkGone410`.
- [ISSUE_151][COMMONALITIES_R4.4] Error responses that combine codes not covered by the catalogue are now defined locally per operation and declare only the codes the operation can return. Their examples reference the shared examples; only `QOS_BOOKING_AND_ASSIGNMENT.*` examples remain inline:
  - [ISSUE_151][ENHANCEMENT] `CreateBookingOrAssign400` split into `CreateBooking400` and `AssignOrReleaseDevices400`.
  - [COMMONALITIES_R4.4] `Generic409` replaced by `DeleteBooking409` (`INCOMPATIBLE_STATE`) and `DeviceAssignment409` (`ABORTED`, `INCOMPATIBLE_STATE`).
  - [COMMONALITIES_R4.4][ENHANCEMENT] `assignDevices` and `releaseDevices` use `DeviceAssignmentNotFound404` (`NOT_FOUND`, `IDENTIFIER_NOT_FOUND`).
  - [ISSUE_151][DECISION] `createBooking` 409 now uses `AlreadyExists409` (`ALREADY_EXISTS` only).
- [ISSUE_151] `sink` in `BookingInput` and `DeviceAssignmentInput` now references the common `Sink` schema.
- [ISSUE_151] `getBookingById`, `deleteBooking`, `getDevicesByBookingId` and `retrieveBookingByDevice` now document `INVALID_ARGUMENT` only for 400 (`OUT_OF_RANGE` no longer listed; these operations have no range-restricted input).
- [ENHANCEMENT] `releaseDevices` 400 now also documents `INVALID_CREDENTIAL`, `INVALID_TOKEN` and `INVALID_SINK`, since the operation accepts `sink` and `sinkCredential`.
- [ENHANCEMENT] API description: API-specific error tables updated (400, 409) and a 422 table added.

### Added
- [COMMONALITIES_R4.4] `sink` is echoed in `BookingOutput` when event delivery is accepted (Event Subscription and Notification Guide, "Sink delivery behaviour").
- [ISSUE_151][COMMONALITIES_R4.4][DECISION] `422 EVENT_NOTIFICATIONS_NOT_SUPPORTED` on `createBooking`, `assignDevices` and `releaseDevices`.
- [ENHANCEMENT][DECISION] `422 QOS_BOOKING_AND_ASSIGNMENT.DEVICE_QUOTA_EXCEEDED` on `assignDevices`, when the request exceeds the remaining device capacity of the booking.

### Removed
- [COMMONALITIES_R4.4] Deprecated error code `CONFLICT` from the 409 responses.
- [DECISION] `INCOMPATIBLE_STATE` from `createBooking` 409.
- [COMMONALITIES_R4.4][ENHANCEMENT] Device identifier 422 codes from `createBooking` (the request has no device).

### Test definitions
- [DECISION] One feature file per operation (`qos-booking-and-assignment-<operationId>-alignedto_r4dot4.feature`), 152 scenarios in total, based on the r4.4 test templates (service, implicit events, C01 device errors) and aligned in wording with the reviewed quality-on-demand-createSession and qos-provisioning-createQosAssignment features.
- [COMMONALITIES_R4.4] Every documented status code and error code is covered by at least one scenario.
- [ISSUE_151] OAS pointers use the `#/components/...` form.
- [ENHANCEMENT] Fields and values aligned with the API: `bookingDeviceCount`, `remainingDevices`, `bookingStatus`, `assignmentStatus`.
- [ISSUE_151][DECISION] The `createBooking` conflict scenario now expects `ALREADY_EXISTS`.
- [ENHANCEMENT] `assignDevices` and `releaseDevices` with more than 50 devices expect `OUT_OF_RANGE` or `INVALID_ARGUMENT`.
- [COMMONALITIES_R4.4] Scenarios that depend on implementation options (synchronous or asynchronous processing, notification delivery, partial success) are marked `CONDITIONAL`.

Additional documentation

This section can be blank.

docs

[Masa8106]

LGTM.