This MR introduces tracking of the `rebase_jid` for merge requests. As
with `merge_ongoing?`, `rebase_in_progress?` will now return true if a
rebase is proceeding in sidekiq.

After one release, we should remove the Gitaly-based lookup of rebases.
It is much better to track this kind of thing via the database.

Add released_at field to releases API
Add released_at column to releases table
Return releases to the API sorted by released_at

This new attribute is optional and used when set instead of the default
format `gitlab+deploy-token-#{id}`.

Empty usernames will be saved as null in the database.

Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/50228.

Use title and description fields for issue trackers

Closes #63690

See merge request gitlab-org/gitlab-ce!30096

- instead of using properties
- backward compatibility has to be kept for now

Add clusters association to deployment

See merge request gitlab-org/gitlab-ce!29960

CE port of https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14108

See merge request gitlab-org/gitlab-ce!29604

We nullify when cluster is deleted as we want to keep the deployment
record around.

Add cluster as an optional association

We will have only cluster for deployments where the build deploys to a
kubernetes cluster