feat: RemoteConfig logic (decide replacement)

[benjackwhite]

Problem

Needs #26534

See https://github.com/PostHog/product-internal/pull/680 for more info.

Generally the idea is that the new flags service will replace the "decide" django endpoint with a much more scalable solution. The thing it won't do necessarily is handle the "remote config" side of things which is currently the other main use for decide.

My idea is to generate the "config" parts into a dedicated helper model which takes care of creating this config derived from the various settings allowing us to do a few cool things:

1. Serve the config as a static file via a CDN - no hot servers needed
2. Back support /decide filling in from the same highly cached concept
3. Build an additional file which is a token-scoped file containing all of the config and all of the posthog-js (one load to rule them all)
4. Allow us to GTM style things for the destinations to inject extra JS loading in a hyper optimal way

Megaissue here

Changes

This PR is just part 1 - generate the RemoteConfigs as and when they should be, with new endpoints to serve them (endpoints that will eventually be served by the CDN instead).

• RemoteConfig class that generates this config as and when it is needed
• Saving writes the data to S3 and invalidates the CDN (at least in a flagged way)
• Tracks a metric so we can alarm on it
• 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
• Fix loading of array.js in code...

Follow up work

• Figure out what to do about the one or two replay things that are "dynamic" (like checking the domain...)
• Bundle dependencies automatically based on configs (i.e. surveys if surveys are enabled, recordings etc.)
• 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

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

Does this work well for both Cloud and self-hosted?

How did you test this code?

[github-actions]

Size Change: +30 B (0%)

Total Size: 1.11 MB

ℹ️ View Unchanged

Filename	Size	Change
frontend/dist/toolbar.js	1.11 MB	+30 B (0%)

_{compressed-size-action}

[posthog-bot]

📸 UI snapshots have been updated

18 snapshot changes in total. 0 added, 18 modified, 0 deleted:

• chromium: 0 added, 18 modified, 0 deleted (diff for shard 1)
• webkit: 0 added, 0 modified, 0 deleted

Triggered by this commit.

👉 Review this PR's diff of snapshots.

[mariusandra]

Cool stuff

[posthog-bot]

📸 UI snapshots have been updated

16 snapshot changes in total. 0 added, 16 modified, 0 deleted:

• chromium: 0 added, 16 modified, 0 deleted (diff for shard 1)
• webkit: 0 added, 0 modified, 0 deleted

Triggered by this commit.

👉 Review this PR's diff of snapshots.

[sentry-io]

Suspect Issues

This pull request was deployed and Sentry observed the following issues:

• ‼️ IntegrityError: duplicate key value violates unique constraint "posthog_remoteconfig_team_id_key" posthog.tasks.remote_config.update_team_remote_... View Issue

_{Did you find this useful? React with a 👍 or 👎}