Move caching logic from CurrentSettings to ApplicationSettingFetcher

What does this MR do and why?

Related issue: #417763 (closed)

Currently, we have settings in ApplicationSetting class. These are accessed using Gitlab::CurrentSetting class. With cells, we will have settings that will move from ApplicationSetting to OrganizationSetting. But we want to keep accessing settings using Gitlab::CurrentSetting.

This MR is the first step of removing ApplicationSetting related logic from CurrentSetting to a new ApplicationSettingFetcher class. It introduces that class and moves the private cached_application_setting to this new class.

Next MR will be related to uncached_application_setting logic (which is more complicated)

Note: in a earlier version of this MR, it was suggested to use a feature flag. However, there is a warning: "Don’t use feature flags at application load time." Gitlab::CurrentSettings is used in initializers so we can not use Feature Flags. By limiting the size of the MR, we can limit the impact of this change.

How to set up and validate locally

Using GDK: Test if updating settings will still reset the cache

• http://localhost:3000 login as administrator
• Ensure the warning about "Check your sign-up restrictions" is displayed and click 'Deactivate'
• http://localhost:3000/admin/application_settings/general#js-signup-settings Remove the checkbox "Sign-up enabled" and click "Save Changes" button
• The warning should now be removed.
• http://localhost:3000/admin/application_settings/general#js-signup-settings Set the checkbox "Sign-up enabled" and click "Save Changes" button
• The warning should be back.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.