feat: Inline plugins (plugins without running VM2)

[oliverb123]

Problem

Plugins run inside a VM, which incurs memory and cpu overhead, and code complexity. As many plugins are now considered trusted-source in cloud environments, we can inline the code for commonly used plugins instead, focusing for now on processEvent plugins, to get some improved performance in the ingestion pipeline.

[tiina303]

Let's build out the frontend and backend changes on top of this to make sure we don't need anything else changed in the model to minimise number of migrations.

[posthog-bot]

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week.

[posthog-bot]

This PR was closed due to lack of activity. Feel free to reopen if it's still relevant.

[benjackwhite]

This is super cool. Some really clean work here (especially when working with such a messy problem!) Only one suggestion regarding tests but not blocking.

We might want to be extra careful merging this. I haven't tried it locally so worth triple checking and if there is any doubts doing a canary style deploy (with support from infra)

[benjackwhite]

I was expecting to find a test for this tbh. At least one happy path test per inline plugin would be great

[oliverb123]

I took the tests from the plugin repo and put them in inline.test.ts (the semvar-flattener one) - does this cover the kind of testing you mean, or something beyond that?

[bretthoerner]

I'm not sure if it's what he meant, but seeing a functional test that actually calls an inline plugin would be nice (maybe I'm missing one?)