feat: don't clone replay event data

[pauldambra]

see: https://posthog.slack.com/archives/C0374DA782U/p1711031505674169?thread_ts=1711030142.540499&cid=C0374DA782U

@benjackwhite do you remember why we clone?

we reducing events so that every session in a batch handled by a consumer is represented by a single message

[
{sessionId: 1, events: [a]}, {sessionId: 1, events: [b]}, {sessionId: 2, events: [c]}, 
]

becomes

[
{sessionId: 1, events: [a, b]}, {sessionId: 2, events: [c]}, 
]

in doing that we clone each object, but the events array can be large

If we do not access the original array of messages after reducing then i think it's safe to reduce without cloning at all.

(looking at usage we parse each message into an array variable and then reduce those parsed messages into the array variable used elsewhere in the code so I think it's safe to not copy here)

[benjackwhite]

I don't think thats true - the tests prove it

[xvello]

This is a step in the right direction. Cloning into reducedMessages would not be necessary if the source message were not available outside of this scope (as in, reduce messages as they are unmarshalled)

[pauldambra]

This is a step in the right direction.

Yep, I knew I'd not be able to make time to focus on this so decided to go for progress over perfection 😊