[RUN AS-IF-FOSS] Resolve admin/license timeout on large instances

What does this MR do?

Caches the count for current active users in a cron job that runs once daily.

Allows larger instances of GitLab, for instance .com, to be able to render the /admin/license page without timing out and sending the UI a 500 response.

The caveat here is that we are switching from an always fresh return of the current active user count to a once-daily freshness of that value.

If that cron job has not run that creates the cache, we'll fallback to the original query.

This will affect the admin area in the following ways:

1. Billable Users only refreshed daily.
2. Maximum Users - if new users were created after the active user count had been refreshed for the day and adding a user after that makes current number the max, this value will not be updated. For instance - if the historical max is 10, and the current active user for yesterday was 10, and then a new user was added, then this page was loaded, it would still show 10 until the next run of the current active user calculation where it would update to 11.
3. Overage counts
4. User count limit warning email
5. current_active_users_count off of the license API
6. active_users off of the GitlabLicenseWithActiveUsers
7. check_trueup during applying of a license as per validation.
8. check_users_limit - opposite of trueup.
9. When showing the warning about thresholds defined here.
10. Tracking of historical changes to the license via http://gitlab.com/gitlab-org/gitlab/blob/bacf7c95091d84f10394f77e0a8907f17fdc90cf/ee/app/models/historical_data.rb#L12-12

Screenshots (strongly suggested)

page changing

Database

Before query using filters - https://explain.depesz.com/s/94bQ

After adding index improvement (no filters) - https://explain.depesz.com/s/BWZc

Migraton output

08:58 $ be rails db:migrate:up VERSION=20201103171537
== 20201103171537 AddIndexActiveBillableUsersToUser: migrating ================
-- transaction_open?()
   -> 0.0000s
-- index_exists?(:users, :id, {:name=>"active_billable_users", :where=>"(state = 'active' AND (user_type is NULL or user_type in (NULL, 6, 4))) and ((users.user_type IS NULL) OR (users.user_type <> ALL ('{2,6,1,3,7,8}')))", :algorithm=>:concurrently})
   -> 0.0090s
-- execute("SET statement_timeout TO 0")
   -> 0.0002s
-- add_index(:users, :id, {:name=>"active_billable_users", :where=>"(state = 'active' AND (user_type is NULL or user_type in (NULL, 6, 4))) and ((users.user_type IS NULL) OR (users.user_type <> ALL ('{2,6,1,3,7,8}')))", :algorithm=>:concurrently})
   -> 0.0512s
-- execute("RESET ALL")
   -> 0.0002s
== 20201103171537 AddIndexActiveBillableUsersToUser: migrated (0.0611s) =======

✔ ~/projects/gdk/gitlab [11752-improve-active-users-count-license-query|✚ 2⚑ 14]
08:59 $ be rails db:migrate:down VERSION=20201103171537
== 20201103171537 AddIndexActiveBillableUsersToUser: reverting ================
-- transaction_open?()
   -> 0.0000s
-- indexes(:users)
   -> 0.0087s
-- execute("SET statement_timeout TO 0")
   -> 0.0002s
-- remove_index(:users, {:algorithm=>:concurrently, :name=>"active_billable_users"})
   -> 0.0028s
-- execute("RESET ALL")
   -> 0.0002s
== 20201103171537 AddIndexActiveBillableUsersToUser: reverted (0.0123s) =======

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team

Related to #11752