Add observability metrics to all report types

What does this MR do?

Add a new observability.events properties to scan. This allows CI-based analyzers the ability to track events via the gitlab internal events api by adding them to the security report. Events can contain any number of additional properties for collection of metrics. The events will be tracked during security report processing in the monolith.

There are three fixed named properties which specifically defined in the schema changes -- property, label, and value. Additional properties are allowed and will get added to the event tracking request. This is a recent change for internal event tracking.

Example usage:

{
  "scan": {
    "observability": {
    "events": [
      {
        # Name of the event
        "event": "api_security",
        # Following 3 properties are columns in the data warehouse
        # they should be used for primary join/filtering
        "property": "scan_uuid", # Allows joining across events
        "label": "openapi|graphql_schema|postman|graphql|har",
        "value": 60, # length of scan in minutes
        # Custom properties stored in a JSON column in the data warehouse
        "operations": 5
        "version": "5.5.5",
        "version_major": 5,
        "operations": 10, # How many API operations we are scanning
        "per-request-script": true,
        "overrides-command": true,
        "status": "completed|failed",
        "content-type": "mixed|graphql|json|xml|soap",
      },
      {
        # This event can be joined via the scan_uuid
        "event": "api_security_cwe_92",
        "property": "scan_uuid",
        "label": "graphql",
        "value": 5, # count of vulnerabilities
        "parameters": 20, # number of parameters check ran on
      },
    ],
  }}
}

What are the relevant issue numbers?

• Collecting CI-based analyzer metrics
• Extend the security report to include metrics
• Allow more than 3 additional properties in Internal Events

Checklist

• Ensure changes can be built upon without requiring a breaking change, see Building for Extensibility.
• Review and add/update tests for this feature/bug.
• Add an entry to the CHANGELOG if required, with the appropriate version. See Classifying Changes.
• Assign the MR to the appropriate person/people for review.

Related to gitlab-org/gitlab#473108 (closed)