Optimize signal ingestion pipeline and create perf-test cli util

[wssheldon]

This PR introduces a blocking thread-safe FIFO queue in the signal ingestion pipeline. This ensures signals are processed in the order they were received and prevents race conditions where a signal instance can override a shared value (e.g. case associations). The queue has a max size of 500 that is also used to limit the number of instances retrieved by the query in process_signals. We also create a scoped_session for each run of the scheduler.

A boundary of .filter(SignalInstance.created_at >= one_hour_ago) was added to the ingestion query to prevent cases where we are unable to keep up for an hour, which should never happen, and if it does is an acceptable scenario to prevent performance issues and outages.

Caching logic was introduced in _should_update_signal_message to prevent the Slack chat.update method from being ratelimited.

Finally, a stress test CLI utility was created that attempts to replicate signal ingestion via the /instances API endpoint.

Usage:

dispatch scheduler perf-test --api-token redacted` --num-instances 5000
...
Sent 5000 of 5000 signal instances:/Users/wshel/Projects/dispatch/src/dispatch/cli.py:send_signal_instances:769
Elapsed time: 281.17 seconds

I tested a push of 5000 instances from my M1 MBP.

timer results:

Non-deduplicated signal instance (calls many external API's) and results in new case.

DEBUG:function.elapsed.time.dispatch.signal.scheduled.process_signal_instance: 29.435003541992046

Deduplicated signal instance.

DEBUG:function.elapsed.time.dispatch.signal.scheduled.process_signal_instance: 0.0374222089885734

We can play around with these configurable options to see what makes the most sense:

@scheduler.add(every(1).minutes, name="signal-process")
MAX_SIGNAL_INSTANCES = 500