Apply Limits to ReactiveCaching for Error Tracking

As detailed in &5051, there are currently no limits for ReactiveCaching and we should implement such Application Limits for the following files in this issue:

• app/models/error_tracking/project_error_tracking_setting.rb

The assumption is that we can use the same default limit value for now, but we can create follow-up issues if each of these project_services models need to have different limits set.

We suggest that other teams also investigate which limit size would work for them, then add the limit to their usage. It's > convenient to first guess the limit behind a feature flag, so if the limit starts breaking something, it's easy to turn it > off until the limit is adjusted. To put the limit check behind a FF flag an easy way could be to override the > reactive_cache_limit_enabled? in your class. Like the following:

class Foo
include ReactiveCaching

  # Set the hard limit
  self.reactive_cache_hard_limit = 10.megabytes

  # Overrides ReactiveCaching default to activate limit checking behind a FF
  def reactive_cache_limit_enabled?
    Feature.enabled?(:reactive_caching_limit_environment, project)
  end

Once the limit is deemed valid in GitLab.com and perhaps also for self-managed by enabling the FF by default, then just remove the FF.