Attribute startsAt should be non-mandatory

[ilya-smirnov-berlin]

Problem description

Currently the attribute startsAt in Event Notification Template is mandatory. When the subscription is used in asynchronous mode and not started yet (status ACTIVATION_REQUESTED, or SUBSCRIPTION_UNPROCESSABLE as suggested in #243) the starting time is not known.
Also the name of the attribute implies a future date-time which is not the case since this timestamp is set to creation time of subscription and is always in the past (compare to QoD API specification: https://github.com/camaraproject/QualityOnDemand/blob/d6a3f239622e7a840ac049dfa8b2c74a3aea87b0/code/API_definitions/quality-on-demand.yaml#L533 ).
According to this fact maybe the description of this attribute can be changed to the past form.

Expected behavior

• startsAt should be optional
• Renaming from startsAt to startedAt
• Description of this attribute should contain only past form verb:
  instead of
  Date when the event subscription will begin/began
  I suggest
  Date and time when the event subscription has started

[rartych]

* startsAt should be optional

It is optional in API Design Guidelines, so it should be corrected in template file .

* Renaming from startsAt to startedAt
* Description of this attribute should contain only past form verb:
  instead of
  _Date when the event subscription will begin/began_
  I suggest
  _Date and time when the event subscription has started_

The Subscription component is currently used in the response only (I think initially it was also placed in the subscription request), the question is whether we should change parameter name within this release, that would impose implementing this change in other subscription APIs (in short time before metarelease ).

[PedroDiez]

Understood the rationale and it makes sense to have it optional.

Regarding the name, I suggest to keep it and not change in anycase as in the description the context will be provided.
We also use "expiresAt" for a future Date.