- The commit count was capped at 10, due to
  `Gitlab::Git::Repository#log` enforcing a limit, with the default set
  to 10.

- Reimplement a small portion of this `log` function to get just the
  data we need.

- Don't use `TableReferences` - using `.arel_table` is shorter!
- Move some database-related code to `Gitlab::Database`
- Remove the `MergeRequest#issues_closed` and
  `Issue#closed_by_merge_requests`  associations. They were either
  shadowing or were too similar to existing methods. They are not being
  used anywhere, so it's better to remove them to reduce confusion.
- Use Rails 3-style validations
- Index for `MergeRequest::Metrics#first_deployed_to_production_at`
- Only include `CycleAnalyticsHelpers::TestGeneration` for specs that
  need it.
- Other minor refactorings.

And `scss_lint`

A number of failures were introduced due to performance
improvements (like pre-calculating metrics).

1. Move the test generation to `CycleAnalyticsHelpers::TestGeneration`

2. Move all helper methods (previously placed in each individual spec
   file) to `CycleAnalyticsHelpers`

Add a `before_end_fn` option to the code that generates cycle analytics
specs. `before_end_fn` is called before the end conditions are. Used for
data setup that needs to be called after the start conditions and before
the end conditions.

Remove overlap from the "start + end" durations in the happy test
case. For the `staging` phase, the end time is the _first_ deployment
that happens after the MR merge.

If we have 5 MRs where the `start_time`s (merge time) are the
same, and all the `end_time`s (deploy to production) a few days from
now, only the earliest deploy will get picked up, because that
consitutes a deploy for _all_ the MRs.

We fix this by removing overlap. Every `start_time` is now generated to
be _after_ the preceding `end_time`.

- Tests would randomly fail because of naming conflicts.
- Use a `random_git_name` method instead of using `FFaker` directly.