[QoS Booking And Assignment] `deleteBooking` behavior when assigned devices remain is implementation-defined and undocumented

[gmuratk]

Problem description

The API does not specify what happens when a consumer invokes DELETE /qos-bookings/{bookingId} while devices are still assigned to the booking. In practice, operator implementations diverge:

1. Some operators reject the DELETE and return 409 INCOMPATIBLE_STATE, requiring the consumer to release all devices first via POST /qos-bookings/{bookingId}/devices/release.
2. Other operators automatically release all assigned devices as part of the DELETE and return success.

Because the API specification is silent on this behavior, consumers have no portable guidance. A consumer that issues DELETE without releasing devices first may receive a 409 from one operator and a 204 from another, making portable consumer code impossible without trial-and-error.

Expected action

The API specification should:

1. Explicitly document both provider behaviors as valid implementation choices.
2. Require API providers to document their specific behavior.
3. Recommend that consumers release all assigned devices before invoking DELETE for portable, provider-agnostic behavior.
4. Confirm that 409 INCOMPATIBLE_STATE is a valid response code for deleteBooking when devices remain assigned.

Additional context

• Affected operation: deleteBooking (DELETE /qos-bookings/{bookingId})
• Affected response code: 409 INCOMPATIBLE_STATE (needs to be documented as a valid response)
• Related operation: releaseDevices (POST /qos-bookings/{bookingId}/devices/release) — the consumer-safe pre-step
• CAMARA Design Guide reference: §5.7.2 Operations — "Functionality methods MUST have a description"; §5.7.6 — all response objects MUST have a description; undefined provider behavior violates the principle that the spec is the authoritative contract

[Masa8106]

This issue was addressed in merged PR (#139). So this issue should be closed.