Add tracking events in API::ContainerRegistryEvent

What does this MR do?

API::ContainerRegistryEvent is an API endpoint that receives notifications from the Docker container registry when an operation occurs.

The notification is basically an action and a target. Even though several actions are defined, this MR adds tracking only for the following actions:

• push
• delete

The interesting targets are:

• tag
• repository

Note that the action for creating or updating any type of target is the same: push. 🤷 (See #20378 (comment 288609238))

As described in the relevant issue #20378 (closed), we want a different tracking event between a (container) repository creation and push. To do so, we read the model ContainerRepository when a push is received for a repository. If the model exists in the database, the action is a push. If not, the action is overriden to create.

The tracking category is set to container_registry:notification.

The possible actions are: push_repository, delete_repository, create_repository, push_tag and delete_tag.

Design choices

• As the Container Registry feature is part of Core, moved the API to the non EE part.
• Created a non EE model ContainerRegistry::Event taking care of the whole process with 3 methods:
  • #supported? to check if the notification json is supported
  • #handle! to handle it.
  • #track! to track it.
• The #handle! part is only creating a geo event for now. This handling is done using EE models. So a EE extension of ContainerRegistry::Event has been added to host this.
• In addition, we fixed a bug with the geo event creation. This part is using find_by! on ContainerRepository but the container repository may or may not be present in the database and this case 💥. This part is now guarded by #container_repository_exists?
• Looping on the notification json and calling ContainerRegistry::Event is so simple that we decided to remove ContainerRegistry::EventHandler and let the API class use ContainerRegistry::Event directly.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team

Closes #20378 (closed)