Ensure worker events are idempotent

Sometimes, during high load, events sent from the worker (ie, step:complete) can time out

When this happens, the information contained in that message is lost forever.

It would be nice, worker-side, to attempt to retry those timedout events after a backoff. There's actually support for this in the worker right now.

The problem is that sometimes events time out after they've been processed. Say a lot is posted, and saved to the database and saved to the user. But the busy websocket cannot reply to the worker within the allowed time, and so throws a timeout.

We have a schrodinger's event: it timed out, but was it processed? We don't know.

Unfortunately the events in Lightning are not idempotent. If we send a log twice, it'll be recorded twice. If we send a dataclip twice, we actually get a critical uniqueness error because we're trying to create a dataclip with a UUID that already exists.

So ideally, the events code would be modified so that the handlers can be called multiple times without any side effects. If submitting a dataclip which already exists, the call is simply a no-op.

Uniqueness may be a bit harder to categorise on log events.

I think we probably need a discussion around this - is it really safe to ignore a dataclip that exists? Will this impact performance? Should we be more worried about why these events are timing out?

Start with the worker event handling for step:complete, then trace the log and dataclip handlers and their database effects. The issue names no files or tests; done means the retry path has an agreed safe behavior for already-processed events, without duplicate logs or dataclips, and the relevant behavior is verified.