Apply Commonalities 0.8.0 enhancements for Number Verification

[bigludo7]

Problem description
List of Commonalities PR relevant for this API

• CAMARA_common.yaml - alignment with OWASP and other linting rules Commonalities#590 - note: we have to add for the x-correlator maxLength: 256 and update description. This is not a breaking change as x-correlator has already a pattern limiting at 256.
• Clarification on string `maxLength' Commonalities#620 - same 590
• fix(design-guide): add rule for undeclared properties in request bodies Commonalities#634
• Add mandatory info.description templates to common artifacts and samples Commonalities#635
• fix: x-camara-commonalities to use full version string Commonalities#599 - handled by the release tool

List of Commonalities PR not relevant:

• New 409 error code called INCOMPATIBLE_STATE Commonalities#550
• docs: add device identifier constraints per #513 Commonalities#576
• Clarification meaning of {{API_NAME}}.{{SPECIFIC_CODE}} Commonalities#541
• Array description guideline Commonalities#559
• Clarifications for asynchronous responses Commonalities#575
• Guidelines and linting rules for OWASP API Security Top 10 Commonalities#582
• Improve authentication mechanism for subscription events Commonalities#580
• Add business-level outcome guidance to API Design Guide Commonalities#578
• Subscription Testing Definitions Enhancements - Private JWT Key scenario Commonalities#583
• Relaxing NAI length restriction from 253 to 2048 Commonalities#597
• Event subscription template - alignment with OWASP and other linting rules Commonalities#591
• feat: add implicit-subscription API template Commonalities#612
• Add pagination shared components and example to artifacts Commonalities#617
• Empty Request Body Test proposal. Template Artifact for 400 Syntax Commonalities#618

Expected behavior
Align the API.
No breaking change

Alternative solution

Additional context
Probably worth to have this Commonalities assessment checked by @rartych or @hdamker

[bigludo7]

Question for the Number verification communities
As the update for Syn26 are not breaking change could we target for a 2.1.1 ?
@AxelNennker @fernandopradocabrillo @jgarciahospital

[rartych]

https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/14557919/API+versioning

• Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior. https://semver.org/#spec-item-6
• Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

[bigludo7]

Thanks @rartych and I was aware of this page.
I understood this is borderline but my proposal is to consider adding the maxLenght to 256 as a patch version in order to avoid any confusion on this API.

[hdamker]

@bigludo7 I recommend to update the Commonalities version in release-plan.yaml to r4.3 and then see which warnings will be brought up by the validation rules. Agree to avoid breaking changes now, even if some warnings will stay then.