LogHog -> PostHog

[martosaur]

It feels weird to create a PR that basically replaces everything, but here we are 🫠 The code is pretty much identical to martosaur/log_hog#18 The biggest key question I think is which big parts of the original should survive.

We probably want to have a temporary branch for that too, since there is a definitely a list of things that should be done before this goes through, if it does at all. For example:

• Partitioning Sender, so that a single process wouldn't become a bottleneck. I think Sentry's event sender is a decent example
• Ensuring that the library plays well with users' async tests
• Clearly splitting high level functions into "convenience functions with reasonable defaults" and lower-level DIY-kit (PostHog.Core for example?)

Anyways, I'm leaving this up to you @rafaeelaudibert to outline the path forward , I'll do what I can to help.

[rafaeelaudibert]

There are a couple of changes needed in this PR before we merge it. I'm happy to do them in this PR rather than waiting for you @martosaur since I know you're fairly busy. I've pointed this to a new v2.0.0 feature branch so that I/we can develop against that branch safely.

@martosaur Can you make sure I have write access to the parent log-hog-invasion (😆) branch?

[rafaeelaudibert]

Do we need this one? It seems like this should be covered by integration.example.exs

[martosaur]

Right! It should be gitignored 😅 luckily this is a public token

[martosaur]

@rafaeelaudibert that's a very short list so all done! But feel free to poke around more

Can you make sure I have write access to the parent log-hog-invasion (😆) branch?

I added you as a contributor to my fork so I think that should do it?