Document default outbound hosts for offline instances

What does this MR do?

At default settings, an instance with no internet access, or with controlled egress, tries to reach events.gitlab.net, snowplowstg.trx.gitlab.net, observe.gitlab.com on GitLab Ultimate and, unless it has an offline license on GitLab 19.5 or later, billing.prdsub.gitlab.net when it emits billable usage events. No page in doc/ names these hosts, so an allowlist built from the docs misses them. The table also names version.gitlab.com and gitlab.com, which the page's existing sections cover without naming the host. It also names storage.googleapis.com, which the settings page gives for the syncs that Package registry metadata to sync chooses. The row adds the CVE enrichment sync, which that setting does not stop.

This adds a table to the offline quick start: each host, what sends to it, the setting that stops it, and whether an offline license stops it.

It also rewrites the "Disable Version Check and Service Ping" section, which said both services can be turned off. In GitLab 17.10 to 19.5, clearing Enable version check does not stop the version check, because the daily cron worker added in 17.10 does not read the setting. Merge request 261398 fixes that for 19.6. With a license other than an offline license, the instance can also send Service Ping with Enable Service Ping cleared. The section now names both settings, links their steps, and states both exceptions.

The assistant measured each row on a self-managed GitLab 19.5.0 test instance with an offline license and outbound traffic blocked, counting connection attempts per host. The billing.prdsub.gitlab.net row and the Service Ping license case were compared with the same version on an online cloud license. The Ultimate scope of the observe.gitlab.com row, the .test host name case and the GitLab 17.10 lower bound come from the code only. The storage.googleapis.com row comes from a run on GitLab 19.4.1 with an offline license and outbound traffic open. With every package type cleared under Package registry metadata to sync, the advisory sync stopped and one hourly CVE enrichment run still downloaded 17.6 MB. @azaydan said the data also serves dependency scanning and that a way to disable it should probably be a toggle of its own, which this MR does not add. The measured rows match the code at master, which also carries the fix above.

• lib/gitlab/tracking/destinations/destination_configuration.rb:7-10,26-31,59-62 sets the hosts and their staging twins.
• lib/gitlab/tracking/event_eligibility_checker.rb:17-19 gates events on Enable event tracking (app/views/admin/application_settings/_product_usage_data.html.haml:17).
• ee/config/schedule.yml:292-294 and ee/app/workers/observability/alert_query_worker.rb:14-16 run the alert job every minute unless Fetch cloud observability alerts is cleared (ee/app/views/admin/application_settings/_gitlab_observability_backend_ssl_verification.html.haml:10).
• app/workers/gitlab/version/version_check_cron_worker.rb:28 skips the version check when Enable version check is cleared (app/views/admin/application_settings/_usage.html.haml:11).
• lib/gitlab/usage/metrics/instrumentations/test_gitlab_net_connectivity_metric.rb:8,13 sends the connectivity test to snowplowstg.trx.gitlab.net while Service Ping is enabled and consented to. ee/lib/ee/service_ping/service_ping_settings.rb:10-12 keeps Service Ping on when the license carries operational metrics, unless it is an offline license, and _usage.html.haml:20-22 then disables Enable Service Ping.
• ee/lib/ee/gitlab/billing_events/client.rb:30-35 skips billing on an offline license in GitLab 19.5 and later.
• lib/gitlab/ci/runner_releases.rb:18-19 reads only its setting, so an offline license does not stop the gitlab.com row.
• ee/config/schedule.yml:304-306 and ee/app/workers/package_metadata/cve_enrichment_sync_worker.rb:21-40 run the CVE enrichment sync every hour when the license has dependency scanning, with no check for an offline license.
• ee/app/models/package_metadata/sync_configuration.rb:48-51 builds its one configuration with no package type, so Package registry metadata to sync (ee/app/views/admin/application_settings/_license_compliance.html.haml:6) does not apply. Lines 161-167 read a local copy first when vendor/package_metadata/cve_enrichment exists.
• ee/app/services/security/ingestion/tasks/ingest_finding_risk_scores.rb:55-60 reads the data for vulnerability findings.

Related issues

• Related to #561085

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

An AI coding assistant wrote this change. The assistant also checked each claim against the code cited above and ran markdownlint-cli2 and Vale on the changed page, with the project's configuration, on a local machine.