Fix quota reset before next release

Today we hit problem of 1th of month where quota was not reset due to SQL timeout.

The problem is with this query: https://gitlab.com/gitlab-org/gitlab-ee/blob/master/app/workers/clear_shared_runners_minutes_worker.rb#L10.

We have:

> ProjectStatistics.count
=> 2385330

This leads to SQL query timeout. Thus we do not reset quotas. And process even that retried do fail.

The simplest fix is to change the offending code:

    ProjectStatistics.where('shared_runners_seconds > 0').
      update_all(shared_runners_seconds: 0,
        shared_runners_seconds_last_reset: Time.now)

    NamespaceStatistics.where('shared_runners_seconds > 0').
      update_all(shared_runners_seconds: 0,
        shared_runners_seconds_last_reset: Time.now)

But this, we limit data set to a reasonable amount and we do not hit the timeout. However, this is still not ideal, as we should reduce the number of updates at a single time to some amount, like 1k-10k.

Original issue: https://gitlab.com/gitlab-com/support-forum/issues/1905

mentioned in issue gitlab-com/support-forum#1905 (closed)

Maybe we could reuse some work by @yorickpeterse, there's a method in the Gitlab::Database::MigrationHelpers that updates rows in batches of 5% of the total amount.

A much better way would be to store these quotas in a separate table with 1 row per project per month. This removes the need for updating anything (the app just updates/inserts data for the current month), and you get to keep an archive of runner time per time period. This can also reduce table bloat.

@yorickpeterse The proper solution for that is scheduled for %9.5: https://gitlab.com/gitlab-org/gitlab-ce/issues/34516. Currently, I have the fix for the problem: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2275.

mentioned in merge request !14785