Refactor configuration schema in CAMARA_event_common.yaml

[rartych]

What type of PR is this?

• correction

What this PR does / why we need it:

Applied the Config → ConfigBase refactor across the Commonalities repo:

1. artifacts/common/CAMARA_event_common.yaml — Renamed Config to ConfigBase, removed the required subscriptionDetail property and its internal $ref, removed the now-unused CreateSubscriptionDetail stub.

2. artifacts/api-templates/sample-service-subscriptions.yaml — Added a locally-defined Config schema that extends ConfigBase via allOf and adds the required subscriptionDetail (typed against a newly added local CreateSubscriptionDetail stub). Updated the two config: property refs (in SubscriptionRequest and Subscription) to point to the local #/components/schemas/Config instead of the common file.

3. documentation/CAMARA-API-Event-Subscription-and-Notification-Guide.md — Added a note under the config attributes table explaining the ConfigBase/Config split and showing the allOf pattern API projects must follow, with a pointer to the updated template.

4. Moved initialEvent out of the Commonalities-owned ConfigBase into the API-project-owned Config schema (alongside subscriptionDetail). ConfigBase now only defines the two truly common attributes, subscriptionExpireTime and subscriptionMaxEvents. initialEvent is documented as a predefined, optional attribute that each API project MAY include in its own Config schema, or omit if sending a notification at subscription creation time does not make sense for its event type(s).

5. Migration required for consuming API repos: Config in CAMARA_event_common.yaml is renamed to ConfigBase. Any API repo that currently does $ref: "../common/CAMARA_event_common.yaml#/components/schemas/Config" must update that $ref to .../schemas/ConfigBase, and explicitly add required: [subscriptionDetail] in their own local allOf extension — this PR removes subscriptionDetail (and its required entry) from the common schema, so it is no longer inherited automatically. Repos that skip the required step will have subscriptionDetail silently become optional.

Which issue(s) this PR fixes:

Fixes #659

Does this PR introduce a breaking change?

• Yes
• No

Special notes for reviewers:

initialEvent was originally kept in ConfigBase alongside subscriptionExpireTime/subscriptionMaxEvents, forcing every API project to inherit it via allOf even when it made no sense for their event type(s) (e.g. no meaningful "current state" to check at subscription time). Since Config is already the per-API extension point for subscriptionDetail, initialEvent follows the same pattern: it is a Commonalities-predefined attribute (same name/type), but declared - and therefore includable or omittable - in each API project's own Config schema with customised description if needed.

Changelog input

Refactored configuration schema in CAMARA_event_common.yaml: renamed Config to ConfigBase and moved subscriptionDetail/initialEvent ownership to each API project's local Config schema.

Additional documentation

[hdamker]

Hi Rafal, an early review of the PR. It implements #659 correctly, repo-wide I found no remaining references to the old Config or the removed CreateSubscriptionDetail stub, and the composed wire format is unchanged. Inline suggestions below for the description gaps and two nits.

One point that doesn't fit a suggestion: some API repos already $ref the old Config anchor directly (e.g. DeviceRoamingStatus, SimSwap), and repos using the current allOf workaround inherit required: [subscriptionDetail] from the common file — after this change they must declare it themselves, otherwise subscriptionDetail silently becomes optional. Worth naming the rename and that migration step in the changelog input / release notes.

[PedroDiez]

Minor editorial

LGTM so far

[rartych]

I have moved initialEvent out of the Commonalities-owned ConfigBase into the API-project-owned Config schema (alongside subscriptionDetail). initialEvent is documented as a predefined, optional attribute that each API project MAY include in its own Config schema, or omit if sending a notification at subscription creation time does not make sense for its event type(s) - following "Up to API project decision to keep it." in current Guide - the wording was changed in this PR.
ConfigBase now only defines the two common properties, subscriptionExpireTime and subscriptionMaxEvents and for them "Up to API project decision to keep it." was removed from the Guide as they are fixed in ConfigBase.

[PedroDiez]

LGTM

[hdamker]

LGTM

[bigludo7]

LGTM

[PedroDiez]

LGTM

[bigludo7]

LGTM

[PedroDiez]

LGTM