ADD emit event when a release is published

⚠️ This is the first part of the merging of the overarching MR, please read its description if you want to understand what is happening here. :) Feel free to ask as many questions as you want if you want to understand the protocol!

Currently, there is no event to which to subscribe if we want to add logic both 1/ when a release is created with not setting a different release date and 2/ when the release date of a pre-existing release record has come. This MR fixes this.

We implement this because we need it for emiting ActivityPub events when the release date has come, thus propagating the news on social media. As this, this MR is part of Add publishing of ActivityPub activities for the releases actor, the overarching MR implementing sending activities out.

Here is how we're implementing this:

1. we add a Release#publish_event_fired boolean field, defaulting to false
2. a cron job checks every hour if a release exists for which release date has come and for which publish_event_fired is not true.
3. for each release matching, it fires an event and toggle the boolean field.

We define "a release which release date has come" as being a release which release date is within a 2 hours interval from current time when the background job is ran.

Note that there is a refactoring opportunity, here, since the evidence creation cron job (implemented here) does a similar job : it will find releases which release date has come to create evidences for them. We don't need two cron jobs for that, the evidence creation job could be refactored to use the more general publish event job. I don't do it, though, because the evidence creation feature is tied to EE which would need to be refactored as well. Since I don't have access to EE, that would be coding in the darkness, blindly trying to make it work and hoping it does, which sounds like A Terrible Idea™. :) I'll leave it to GitLab staff.

How to set up and validate locally

This MR does not do much by itself and is part of the whole feature from the overarching MR, so it's best to use the branch with all the commits and follow its way to set up and validate locally to test what is related to this MR in the process. Unless you feel like writing a worker subscribing to the event provided here to test it. :)

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.

Related to &11247