Be resilient against duplicated webhook events

[waiting-for-dev]

There's no guarantee that Stripe will send a webhook event only once (e.g., our server could timeout for the response while we've actually processed it; in that case, Stripe would retry). We need to ensure that we only process events once or that the subscribers are designed in an idempotent way.

Partially replaces #160

[loicginoux]

Not saying it's the definite solution but as discussed in #189 (comment) having an internal state machine and validating transitions might solve this problem as well...

[waiting-for-dev]

All of the webhook handlers we'll be shipping should be idempotent:

• payment_intent.succeeded will do nothing if the payment is already completed.
• payment_intent.payment_failed will do nothing if the payment is already canceled.
• payment_intent.canceled will do nothing if the payment has already been voided.
• charge.refunded will sync all refunds in an idempotent way once Avoid duplicated Solidus refunds #281 is merged.

At least for this initial release, it can be an acceptable compromise to ship with nothing more robust at a higher level. In order to provide enough flexibility for a user to build their own system, we could modify omnes to allow adapters to be configured at the subscriber class level and have a top-level subscriber class for Stripe webhook handling.

[waiting-for-dev]

With #285, we also acknowledge race conditions for duplicated events. Once that's merged, we can close this issue and re-take the work on the topic if we find time to work on configuring subscriber-level adapters on Omnes (which shouldn't be a great effort).