posthog-destination: fix an issue with the tracking of anonymous users

[jspizziri]

Currently, it seems to us that there are a few issues with the tracking of anonymous users. First I want to specify that the term "anonymous" is overloaded here. There are 3 categories of events, and I'll specify some terms I'll refer to them by to keep them straight:

1. Anonymous/Unidentified - Events that occur before a user has identified themselves, which should have some sort of anonymousId associated with them. Importantly, we do intend to merge these events into an identified user/"Person" at some point.
2. Identified - Events that occur after a user has identified themselves.
3. Anonymous/Anonymous - Posthog "anonymous" events which are intended never to have identifiable information associated with them. Importantly, these events should never be merged into a "Person" record.

When Enable Anonymous User Profiles Is Enabled

When this setting is enabled, over multiple sessions where the user starts as Anonymous/Unidentified and then becomes Identified, currently, you'll end up with duplicate "person" records in Posthog for that user. While there is an alias event that connects the two of them together, they don't get merged into a single record as they should properly be. Therefore, overtime you accumulate a large set of distinct "Person" records in Posthog all containing the Anonymous/Unidentified event history of a user prior to identification, with aliases back to the true identity with the actual Identified events.

By default, all Posthog events are associated with a person profile. Therefore, identify should not be called for a Anonymous/Unidentified user, but rather only called for the actual Identified user and then immediately aliased to the Anonymous/Unidentified users' previous distinctId. This merges all the users' data (both Anonymous/Unidentified & Identified) into a single record.

When Enable Anonymous User Profiles Is Disabled

If you disable this setting, no events are sent to posthog at all, whereas what I would expect would happen is to have Anonymous/Anonymous events sent to Posthog.

[jspizziri]

This documentation video also is a good source of information on this:

https://www.youtube.com/watch?v=3afzkLS-zQA

[absorbb]

@jspizziri

Thank you!

this PR will enable anonymous events capture for clients that have enableAnonymousUserProfiles disabled.
That may be unwanted or unexpected.
I assume that we need the extra boolean flag e.g. sendAnonymousEvents which when not present will take value of enableAnonymousUserProfiles flag

And also improve description of enableAnonymousUserProfiles flag in UI.

We need some time to make sure that no other unwanted side effect will occur for existing clients.

[jspizziri]

@absorbb

Thanks for taking a look. Yeah, I assumed there might be a need for additional user config options. I've never put in the work to get the stack running locally :), nor did I actually run the code in the PR locally (although I tested my research via direct REST calls to the Posthog API). LMK if there's anything I can do to help get this over the line.