Add a resilient sidekiq client

There are generally four situations the app can be in
when a webhook comes in:

• Stable, everything is handled well.
• Programming error, which should 500.
• Postgres is unavailable; in this case, we use the resilient
  logged webhooks, which will automatically retry the webhook later.
  It stores the webhook in another Postgres in the meantime.
• Redis in unavailable; in this case, we were 500ing,
  but because the LoggedWebhook insert succeeded,
  we would never retry the webhook.

This last condition means we didn't make the uptime guarantees
we otherwise should be, allowing us to ingest webhooks for processing
even when data stores are unavailable.

To solve this, we add a new 'resilient' sidekiq client
that will push to a Postgres database, the same way logged webhooks
write to a Postgres database if the initial insert succeeds.

Using the same logic as resilient logged webhooks,
we replay these events when Redis becomes available.

In this case, because the job is done async,
we can still 200 from the webhook handler;
it doesn't matter to the caller whether we are processing the job
directly via Sidekiq, or through the resilient postgres datastore
and then eventually onto Sidekiq.

Refactor LoggedWebhook::Resilient into reusable base class and helper

Fix non-optimal query in avoid_writes?

Was using COUNT with LIMIT 1,
which doesn't do anything.