All the code that pre-calculates metrics for use in the cycle analytics
page.

- Ci::Pipeline -> build start/finish
- Ci::Pipeline#merge_requests
- Issue -> record default metrics after save
- MergeRequest -> record default metrics after save
- Deployment -> Update "first_deployed_to_production_at" for MR metrics
- Git Push -> Update "first commit mention" for issue metrics
- Merge request create/update/refresh -> Update "merge requests closing issues"

The observed faulty state transition is probably hard to test,
because we need to hook into internal states to observe them.
Namely this:

    07:30:16 | Build#ruby-2.2 enqueue: created -> pending
    07:30:16 | Pipeline#32    enqueue: created -> pending
    07:30:16 | Build#ruby-2.3 enqueue: created -> pending
    07:30:16 | Build#ruby-2.2     run: pending -> running
    07:30:16 | Pipeline#32        run: pending -> running
    07:30:29 | Build#ruby-2.2    drop: running -> failed
    07:30:29 | Pipeline#32        run: running -> running
    07:30:29 | Build#ruby-2.3     run: pending -> running
    07:30:30 | Pipeline#32        run: running -> running
    07:30:57 | Build#gem:build   skip: created -> skipped
    07:30:57 | Pipeline#32       drop: running -> failed
    07:30:57 | Build#gem:release skip: created -> skipped
    07:30:57 | Pipeline#32       drop:  failed -> failed
    07:30:57 | Build#ruby-2.3    drop: running -> failed
    07:30:57 | Pipeline#32       drop: running -> failed
                                       ^^^ Should be failed -> failed

However, the consequence of this, executing hooks twice would be
easy enough to observe. So we could at least test against this.
Keep in mind that if we ever changed how we execute the hooks
this won't be testing against faulty state transition.

real pending time, because that's actually by definition,
(the time that it's not running!)
or we could end up with awfully complicated algorithm :(

retries and probably also manual actions!

Feedback:

* https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6084#note_14735478
* https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6084#note_14737804

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5734#note_14056642

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5620#note_13811203

This change simplifies a Pipeline processing by introducing a special new status: created.
This status is used for all builds that are created for a pipeline.
We are then processing next stages and queueing some of the builds (created -> pending) or skipping them (created -> skipped).
This makes it possible to simplify and solve a few ordering problems with how previously builds were scheduled.
This also allows us to visualise a full pipeline (with created builds).

This also removes an after_touch used for updating a pipeline state parameters.
Right now in various places we explicitly call a reload_status! on pipeline to force it to be updated and saved.

So that we could easily access it for the view

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5620#note_13581143

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5620#note_13580861

spec/lib/gitlab/data_builder/pipeline_data_builder_spec.rb

Because it would trigger the event just after saved and it would load
no builds and cache it. We should really avoid adding more magic.

Closes #20115