Use ApplicationContext for FallbackOrganizationTracker

What does this MR do and why?

Gitlab::Current::Organization falls back to the default organization when it cannot resolve one from params, headers, or the current user. This fallback is temporary and must be removed eventually, so we need to track where and how often it happens.

Today, Gitlab::Organizations::FallbackOrganizationTracker.trigger sends an internal event (fallback_current_organization_to_default) through Snowplow. This data is hard to analyze, and the volume of events has become a problem.

This MR moves the tracking to Gitlab::ApplicationContext instead. The information then shows up as json.meta.organization_source on our log lines (for example in Kibana), which is easier to query and correlate with other request data.

The plan is to partly enable the feature flag and and try to bring the number of matches for json.meta.organization_source:fallback to zero.

Changes:

• Add a new organization_source key to Gitlab::ApplicationContext (type Symbol). This key is web-only, so it is not included in the Sidekiq job deletion matching logic or in the admin delete_jobs GraphQL mutation.
• FallbackOrganizationTracker.trigger(value) now pushes organization_source: value into the application context instead of sending an internal event. Current#organization calls it with :fallback. We no longer need the old event label (caller_id), because meta.caller_id is already present on the same log line.
• The Sidekiq middleware Gitlab::SidekiqMiddleware::CurrentOrganization::Server now pushes organization_source: :context when it sets Current.organization from the job context that was propagated at enqueue time. Note: this value appears on log lines written while the job runs, not on the Sidekiq done line, because that line is built from the job payload captured at enqueue time.
• Both of these pushes stay behind the existing ops feature flag track_organization_fallback, which defaults to off.
• The possible values right now are :fallback and :context. If the key is missing from a log line, the organization was resolved normally, from params, headers, or the user.
• Remove config/events/fallback_current_organization_to_default.yml. The related metric, counts.count_total_fallback_current_organization_to_default, is set to status: removed. We keep the metric definition file in the repository, as required by the metrics lifecycle documentation.

Resolves #606297 (closed)

How to verify

1. In a Rails console, enable the feature flag:

   Feature.enable(:track_organization_fallback)

2. Make an anonymous API request that does not specify an organization, for example:

   curl http://gdk.test:3000/api/v4/version

   Anonymous requests without organization params fall back to the default organization, so this should trigger the tracker.

3. Pass an Organization ID, for example:

   curl -H "X-GitLab-Organization-ID: 1000" http://gdk.test:3000/api/v4/version

   It will print no organization source

4. Check log/api_json.log for the request's log line. It should contain "organization_source":"fallback" inside the meta object.

If you have jq, you can run tail -f log/api_json.log | jq -c '.["meta.organization_source"]' and see

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.