Create new Service Ping metrics to track CI Leading Indicators

Summary

With the help of @jreporter, we defined Product Health Indicators for CI. For some of these indicators, there is no existing Service Ping metric. We need the help of the engineering team to create these metrics to support tracking CI Product Adoption.

Requested Metrics

1. Implemented in !163352 (merged) Number of repos running CI jobs (7d, 28d, All-time)
   • Implementation: Emit an event with project_id when a pipeline runs
2. Implemented in !163352 (merged) Number of projects with a gitlab-ci.yml file populated (current number as of ping)
   • Implementation: Emit an event when a pipeline runs with project_id in the event and config_source and source as additional properties (one as label, the other as property). The metric is a unique counter by project.id with a filter restricting to config_source == repository_source. Might be able to re-use the create_ci_internal_pipeline event by adding an additional property.
3. Number of commits to configuration file (28d, All-time)
   • Needs clarification. Should probably be changed to number of pushes to the default branch modifying the CI configuration file. This can be built by emitting an event in the branch hooks of PostReceive when the push is to the default branch and the object id of the CI configuration file is different between the new and old commit SHA for the branch.
4. Implemented in !163352 (merged) Number of pipelines from CI files in repository (28d; counts.ci_pipeline_config_repository is the all-time equivalent)
   • Implementation: A different aggregate on the same event as number 2
5. Implemented in !163352 (merged) Number of pipelines run using schedules (28d; counts.ci_pipeline_schedules is the all-time equivalent)
   • Implementation: A different aggregate on the same event again, with a filter on source
6. Number of passing pipelines (28d, All-time)
   • Implementation: New event, emit event when a non-external pipeline enters a finished state, with status as an additional property. Aggregate on the status.
7. Implemented in !163352 (merged) Total pipelines run (28d, All-time)
   • Needs clarification: If it's the number of completed pipelines, then re-use event from 6. Otherwise, if it's the number of created pipelines, re-use event from 2.

Implementation notes

• Follow the docs for defining events and defining metrics
• Use the additional properties label and property for filtering when defining metrics
• Consider re-using the event create_ci_internal_pipeline where appropriate