Motivation

While looking to implement the usage analytics for the API Gateway service, I've noticed three things:

• we were not sending usage analytics anymore since remove legacy runtime in localstack/service/infra.py #11202, as we removed the code to send it, but didn't register the hook back
• the usage counters were still counting even though analytics would be disabled, and would only skip sending the data over
• the usage counters are using lists that are growing unbounded, possibly using large amount of memory for very long lasting sessions (we're aware of 20+ hours sessions)

This PR mainly does 2 things:

• re-register the hook so that we send analytics over
• it does not count if analytics is disabled
• refactor the counter a bit to avoid growing a list, instead keeping the "set" entries and counting with itertools.count which is thread safe in CPython

I don't really like the boolean check for every call to increment and such, we could probably refactor our counters to be no-op classes if the analytics are disabled? But this at least prevents the memory leaks for users with DISABLE_EVENTS=1 as a quick fix before v4, while re-enabling sending the analytics over.

As a sanity check, I've run some small benchmarks with timeit:
Setting 1 000 000 values in the state:
Performance:

• 0.236s for the new counter
• 0.199s for the old counter with append

Memory:

• 384 bytes for the new counter
• 8448728 bytes for the old counter with append

Changes

• register aggregate_and_send with @hooks.on_infra_shutdown(should_load=lambda: not config.DISABLE_EVENTS)
• don't count if DISABLE_EVENTS is true
• small refactor of the UsageSetCounter
• small change: added the count aggregation method
• fix the median calculation, as it would have been incorrect without sorting the list first

Follow-up

I'm following with #11854 which might contain more controversial changes, related to our counters. I believe the UsageCounter could be simplified into a really simple counter for less complex use case with no aggregation (like lambda:hotreload), and rename the current counter into a somewhat "timing" related counter with aggregation for more complex use cases.

Multithreading testing:

With this small test, we would always end up with the right amount of counting, just for sanity check.

iter_counter = UsageSetCounterIter("namespace")

def incr_iter(*args, **kwargs):
    iter_counter.record(random.choice(["test", "test2", "test3", "test4"]))

with ThreadPoolExecutor(max_workers=1000) as tp:
    p = tp.map(incr_iter, range(100000))

    for _ in p:
        pass

    print(sum(iter_counter.state.values()))
    > always prints out 100000

\cc @cloutierMat thanks for the help and pairing on this! 🙏