Expose integrated error tracking to UI and services

What does this MR do?

Makes it possible to render errors stored in GitLab database.

Some background:

1. We already have UI in place for rendering errors but it uses sentry API as data source
2. Sentry errors are rendered through Gitlab::ErrorTracking::Error* models (not AR models, no database) that are built based on json data from sentry API.
3. ErrorTracking::ProjectSettings is doing too much. Its not only "settings" but also used as a middleman for all data taken from Sentry API.
4. In previous merge requests we introduced integrated error tracking (errors received and stored in GitLab database). But there is no way to see them in UI

What was done:

1. Add compatibility methods to ErrorTracking::Error, ErrorTracking::ErrorEvent models so it can be treated like the one coming from Sentry API
2. Add integrated boolean to ErrorTracking::ProjectSettings to alter the behavior. If true then we use our integrated error tracking instead of sentry API.
3. Introduce fork in logic so services can query either database or ErrorTracking::ProjectSettings for errors depends on feature switch.
4. Put behind the existing feature flag integrated_error_tracking

In long-term I hope for:

1. We get rid of Gitlab::ErrorTracking::Error* classes. We'll use ErrorTracking::Error for everything.
2. We introduce some abstraction layer so we can get rid of if/else condition in services.
3. We refactor ErrorTracking::ProjectSettings to handle only settings. We work with sentry API through some other object.

Issue #329596 (closed). See TODO section there for more steps

The feature is behind a feature flag

How to test

1. Seed error tracking to random project
2. Visit the error tracking page of that project PROJECT_URL/-/error_tracking

bundle exec rake db:seed_fu FILTER=error

Database migrations

rake db:migrate

❯ be rake db:migrate RAILS_ENV=test                                                                                                                                                                                                                        dzaporozhets@DZ-GitLab-MBP-15
== 20210726134950 AddIntegratedToErrorTrackingSetting: migrating ==============
-- add_column(:project_error_tracking_settings, :integrated, :boolean, {:null=>false, :default=>false})
   -> 0.0041s
== 20210726134950 AddIntegratedToErrorTrackingSetting: migrated (0.0042s) =====

== 20210728110654 AddStatusToErrorTrackingError: migrating ====================
-- add_column(:error_tracking_errors, :status, :integer, {:null=>false, :default=>0, :limit=>2})
   -> 0.0026s
== 20210728110654 AddStatusToErrorTrackingError: migrated (0.0027s) ===========

rake db:rollback

== 20210728110654 AddStatusToErrorTrackingError: reverting ====================
-- remove_column(:error_tracking_errors, :status)
   -> 0.0029s
== 20210728110654 AddStatusToErrorTrackingError: reverted (0.0030s) ===========

== 20210726134950 AddIntegratedToErrorTrackingSetting: reverting ==============
-- remove_column(:project_error_tracking_settings, :integrated)
   -> 0.0025s
== 20210726134950 AddIntegratedToErrorTrackingSetting: reverted (0.0026s) =====

Screenshots or Screencasts (strongly suggested)

This merge request does not change the UI. Instead it introduces an alternative data source for existing UI. The end goal is for error tracking pages to look and behave the same for both sentry API and local data.

Does this MR meet the acceptance criteria?

Conformity

• I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
• I have added/updated documentation, or it's not needed. (Is documentation required?) => No documentation yet since you cant activate feature without rails console. Its still in development.
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.
• This change is backwards compatible across updates, or this does not apply.

Availability and Testing

• I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)