Timestamps, ISO8601 and IDDs

The 4.1.3 version of the mandatory core services uses a date/time format that does not strictly adhere to any popular standard for machine-readable timestamp. While Arrowhead should not force the use of any one particular date/time format, we make it more convenient for users of the core services and systems if we are consistent about what formats we use.

_I propose that:_

1. Only ISO8601 strings on the form `yyyy-mm-ddThh:ii:ss(.z{1,9})?Z` be used for timestamps by the Service Registry, Authorization System, Orchestrator and the other core systems. An example of a compliant timestamps would be `2020-06-17T11:18:23.143Z`. Note that the ending `Z` indicates that the timezone is UTC. Also, the number of decimals after the second part could be allowed to vary between 1 and 9. If zero subsecond decimals are used, the dot (.) must be omitted.
2. The IDD of every core service that has at least one interface/function serving data objects containing timestamps should explicitly document that the ISO8601 date/time format is used, that the UTC timezone is always used, and that any number of subsecond decimals of between 0 and 9 digits may be used.

_The advantages of these changes are:_

1. Decreases implementation burden for service integration by consistently using the same format.
2. Improves room for code generation by being explicit about how date/time strings are formatted in IDDs.

_The disadvantages of these changes are:_

1. Breaks compatibility with systems that rely on the existing date/time format.

_Unresolved and related issues are:_

A. There should exist some default way of documenting what date/time format a particular IDD uses. Could something like a Communication Profile (CP) be created for ISO8601 timestamps? The existence of such a CP could also make it easier to model service data objects, as the modeller would only have to refer to whatever "data types" (date/time formats) are defined by the CP.

Start by reviewing the timestamp handling and IDDs for the Service Registry, Authorization System, Orchestrator, and other core systems. Determine the compatibility impact of adopting the proposed ISO8601 UTC format, resolve whether a Communication Profile is needed, and document the chosen format consistently in every affected IDD.

Written by the indexing model from the issue text.