Add common services for logging the progress of a Resource lifecycle transition

[Daniel Vaccaro-Senna]

Is your feature request related to a problem? Please describe.
There is a requirement on the Ansible Lifecycle Driver (which uses this framework) to log the process of a playbook execution, so the user could be provided with live progress of Resource lifecycle transition/operation.

This requirement can be abstracted from Ansible playbooks to cover all types of tasks performed by drivers e.g. for ANY Resource lifecycle transition/operation I would like to see live progress updates.

As a result, Ignition should provide a framework for providing live updates via events. All events should be considered a type of "Resource Transition Progress Event".

The framework should provide a common way to transmit these events to TNCO (so TNCO could present them to the user), with a common look/feel to them. However, there should be adequate flexibility for the drivers to customise the detail of each event with information specific to their implementation (e.g. allow the Ansible driver to transmit events specific to Ansible playbooks).

Describe the solution you'd like

• A new event log service which is bootstrapped into the driver application on start-up.
• Add a base class for events to ignition.model: ResourceTransitionProgressEvent
• The event log service should provide a function to send a new event. No guarantees need to made on the delivery of the event.
• The above function should accept the event as a parameter.
• The event log service will initially use a logger to write the event to log files in a machine readable format (but one that is also suitable for humans e.g. YAML/JSON) form so it can be scraped and parsed later
• Support a "prettier" format for when the flat log type is used in development/testing
• The messages logged by the event log service must include all tracectx headers

Initial schema for ResourceTransitionProgressEvent:

eventType:
  type: string
  description: To remain consistent with other TNCO events, this event type field indicates the payload is for a Resource Transition Progress event
  fixedValue: ResourceTransitionProgressEvent
progressEventType:
  type: string
  description: Considered a "sub event type". Describes the type of event taking place within the context of the driver implementation
details:
  type: object
  description: Details of the event, deliberately schema-less so the driver implementation can add any relevant information

We should considering encouraging a naming convention for values of progressEventType to:

• prevent collision between the names of events from 2 different drivers; but
• allow drivers to use consistent names for common events

The initial proposal is to encourage progressEventType values to use the following format:

<group>/<name>

group - the driver name/type or any other valid name for a logical grouping of events
name - the associated name of the event in the group

For example, the Ansible driver could produce events such as:

• ansible/PlaybookStart
• ansible/TaskStart
  Whilst the Kubernetes driver could produce:
• kubernetes/ObjectCreated
  But both drivers could produce:
• common/SomeCommonEvent