Send notifications for all qosStatus changes

[hdamker]

Problem description

The documentation within v0.10.0 doesn't currently define precisly for which qosStatus changes a developer can expect to receive a notification, see the description below (and which notifications must be implemented by an QoD API provider).

The discussion topic (see below) suggested to send notifications for all changes of the status of the QoS Session resources, including the initial entering of "available" and the ones induced by API calls by the API consumer (e.g. delete of the QoS session). This behaviour was agreed within the QoD call of Dec 15th.

Expected behavior

The documentation describes the expected behaviour. Test cases are defined for all qosStatus changes.

Alternative solution

Additional context

Discussed in #242

^{Originally posted by shilpa-padgaonkar December 12, 2023}
As far as I can understand, if response to create session leads to qosStatus "requested", then the developer can later receive the notification, qosStatus "available". However if the create session response leads directly to qosStatus "available", the notification with status "available" will be skipped. Similarly, before explicit delete session or delete session due to timer expiry, there is no notification sent as qosStatus "unavailable". Is this understanding correct?
If yes, what is the thought around always sending notifications whenever qosStatus becomes available or unavailable (due to whatever conditions).

[hdamker]

This issue will get fixed by #258

[hdamker]

#258 is merged and part of v0.10.0-rc2