feat(autoscaling): Make autoscaling load signals pluggable - #2359

Description

• The ConcurrencySystem now decides whether the machine is overloaded through load signals that you can tune, switch off or extend with your own.

• The new load_signals option takes LoadSignalsOptions, with options for each built-in signal (memory, event loop, CPU and storage client), False to switch one off, and custom for signals of your own.

• The built-in signals are public classes (MemoryLoadSignal, EventLoopLoadSignal, CpuLoadSignal, StorageClientLoadSignal), so you can wrap one instead of reimplementing it. A custom signal matches the LoadSignal protocol, and SnapshotStore keeps its snapshots for the sampled window.

• The two evaluation windows, current_history (5 s) and snapshot_history (30 s), are options of the ConcurrencySystem and apply to every signal. Each signal is told on start which window it's sampled over and which Configuration to read its limits from.

• A duplicate signal name raises ValueError.

• SystemInfo reports custom signals in load_signal_info, and client_info is renamed to storage_client_info.

• Configuration.max_client_errors now defaults to 3, the same as Crawlee JS.

The new "Load signals" section of the scaling guide shows how to switch a signal off, write your own and wrap a built-in one.

Issues

• Closes: Make autoscaling load signals pluggable #2134

✍️ Drafted by Claude Code