RemoteConfig Megaissue

[benjackwhite]

RemoteConfig Megaissue

See the RFC.

We're going to try and move as much as we can of our "decide" endpoint into static configs, driven largely by a CDN so that we can dramatically reduce how much we hit our existing endpoint as well as providing a migration path to the new "flags" service.

MVP

Initial implementation here: #26348

• RemoteConfig class that generates this config as and when it is needed
• Generates a config json, a config js and an array.js on endpoints /array/...
• Tracks a metric so we can alarm on it
• Flagged UI for this new array.js
• Generates a second file that actually includes the site_apps code to be executed
• Generates a third file that is a personalised array.js loader
• Check if this breaks array.js.map for the extra configs
• Figure out what to do about the one or two replay things that are "dynamic" (like checking the domain...)
• Cronjob that takes care of ensuring things are in sync (just in case)
  • Maybe do this with a hash or something so we can detect whether changes are necessary or not
• Decide endpoint having an option to use this RemoteConfig instead of the existing team access (with tests to cover it all)
• Hook up to CDN and add cache invalidation
• Add missing listener for quota limits changing

Future work

• Bundle dependencies automatically based on configs (i.e. surveys if surveys are enabled, recordings etc.)
• Update Mobile SDKs
• Update PostHog JS
• Setup legacy decide endpoint for flags service
• Add surveys to the remote config (either as normal or its own config endpoint

Debug info

- [ ] PostHog Cloud, Debug information: [please copy/paste from https://us.posthog.com/settings/project-details#variables]
- [ ] PostHog Hobby self-hosted with `docker compose`, version/commit: [please provide]
- [ ] PostHog self-hosted with Kubernetes (deprecated, see [`Sunsetting Kubernetes support`](https://posthog.com/blog/sunsetting-helm-support-posthog)), version/commit: [please provide]