feat: Modularize SystemStatus to allow custom backpressure mechanisms

[janbuchar]

• The autoscaling pipeline was hardcoded to four resource types with no way to add new overload signals
• I extracted a LoadSignal interface and SnapshotStore with fromInterval/fromEvent factories, rewired the four built-in resources as signal implementations, and made SystemStatus iterate over all signals in one loop. New signals like navigation timeouts can now be passed in via systemStatusOptions.loadSignals with zero changes to the core.
• It should be fully backwards-compatible
• This should make implementing feat: add network-aware navigation-timeout backpressure #3476 way more straightorward - no more building a parallel concurrency-control system with unforeseeable interactions with AutoscaledPool
• Also relevant to Scale down when a high failure rate is detected #3305

[nikitachapovskii-dev]

Thank you so much for addressing this problem, I really appreciate it!

[nikitachapovskii-dev]

I’m a bit puzzled about loadSignals.
If I understand it correctly, SystemStatus now evaluates both:
the built-in signals coming from Snapshotter and
user-provided signals passed via systemStatusOptions.loadSignals
And if a user provides a custom signal named e.g. memInfo, cpuInfo, it will overwrite the corresponding built-in field in the resulting SystemInfo?

Is that expected, or should the built-in signals remain reserved?

[janbuchar]

Well, I think we should let users overwrite the default memory/cpu/... signals if they know what they're doing. If everyone agrees, I guess let's sure that that's really the case and document it properly.

[l2ysho]

should we cover new loadSignals option in tests? 🤔

[janbuchar]

should we cover new loadSignals option in tests? 🤔

Thanks @l2ysho, added two basic ones to autoscaled pool test suite.