Update geofencing.yaml for release candidate 0.1.0-rc

[akoshunyadi]

What type of PR is this?

• enhancement/feature

What this PR does / why we need it:

According to #112

Prepared release-candidate 0.1.0-rc, including some corrections

Which issue(s) this PR fixes:

Special notes for reviewers:

Changelog input

- Changed version to v0.1.0-rc

Additional documentation

[jlurien]

Hi @akoshunyadi, please take a look into the conflicts, due to the other PR https://github.com/camaraproject/DeviceLocation/pull/115 being recently merged

[jlurien]

We can also adjust some misalignments regarding Errors:

• Generic400: Change description and message in example to: "Invalid argument"
• Generic401: Change description and message in example to: "Unauthenticated"
• Generic403: Change description to "Permission denied"

as in https://github.com/camaraproject/DeviceLocation/pull/104/files#diff-4d5f8ffcf7c3ed5fd9dcf63999a1413cba4fee213f2ae8dbf67efc460427a1ccR370-R395

[rartych]

Since multiple examples are not possible in Schema Object prior OAS 3.1.0 I propose to modifySource component definition as follows:

Source:
      type: string
      format: uri-reference
      minLength: 1
      description: |
        Identifies the context in which an event happened - be a non-empty `URI-reference` like:
        - URI with a DNS authority:
          * https://github.com/cloudevents
          * mailto:cncf-wg-serverless@lists.cncf.io
        - Universally-unique URN with a UUID:
          * urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66
        - Application-specific identifier:
          * /cloudevents/spec/pull/123
          * 1-555-123-4567
      example: "https://notificationSendServer12.supertelco.com"

[jlurien]

@akoshunyadi , @rartych , please tale a look to the new Device model approved by QoD: https://github.com/camaraproject/DeviceLocation/issues/117

I have already adjusted location-verification.yaml

[bigludo7]

Thanks @akoshunyadi 2 smalls comments:

• I understood you used same description for datetime but are we sure it's not better to have explicit description for startsAt & expiresAt attribute ? Not a blocker for me but @JoachimDahlgren point was to have explicit description.
• This description must have following sentence also: It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z)in order to be aligned with the guideline (https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#115-data-definitions)

[akoshunyadi]

@bigludo7 sure, I can change that, I think also other date-time fields are affected.