Stricter validation of Aggregated & TotalCount metrics

What does this MR do and why?

Related to #416666 (closed)

Add more validation for Service Ping metrics.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

1. Try to create/update a metric into something that doesn't pass the new validations:
   • a metric with internal_events data_source and TotalCountMetric instrumentation_class [eg. update this metric] and any of:
     • options not being exactly an object with an events property that is an array of strings
     • events not being an array of objects that have exactly one property: name
   • a metric with redis_hll data_source and AggregatedMetric instrumentation_class [eg. update this metric] and any of:
     • options is not exactly an object with aggregate and events properties
     • options.events is not an array of strings
     • options.aggregate is not exactly an object with operator and attribute properties
     • options.aggregate.operator has value other than OR or AND
     • options.aggregate.attribute is not a string
2. Run the spec checking validity: bundle exec rspec ./spec/lib/gitlab/usage/metric_definition_spec.rb:45.
3. The spec should fail

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.