Dynamic Heap memory consumption management

Recently we have seen a spate of OOM crashes because of very large document ingestion.

With complex configs, multiple pipelines, user set batch size, user set worker thread counts and thread safe outputs we increase the chances of 'drive by' OOM crashes that are not attributable to memory leaks.

Consider the idea of reducing the number of inflight events when LS heap memory consumption reaches a threshold. Logstash could be said to move from a running to a throttling state

These states are global to LS across all pipelines.

Maybe its time for a state machine that tracks whether LS is in starting, running, stopping or throttling states.
#### Transient Memory pressure:

We can reduce the number of inflight events by reducing the batch size, or pausing the PQ ReadClient to allow the current workers to complete their work and reduce the Heap size.
Or maybe a combination of the two, e.g. from 70% to 80% reduce the batch size, then over 80% pause the Read Client.

The transition from throttled to running is triggered when the Heap size falls below a threshold.
#### Memory Leaks:

If after the ReadClient is paused the memory usage does not reduce as the last batch completes then there will be no outgoing events per second and LS will appear to have hung, except it will have logged that it is changing to the throttling state so we can induce that there is a memory leak or a bug that appears to be a memory leak. LS will need restarting.
However the input side was not blocked until the PQ fills up completely, also logged, so some degree of safety and correct shutdown is attained.

No files, tests, or entry points are identified. Start by tracing Logstash heap usage, inflight events, batch sizing, and the PQ ReadClient, then map how global pipeline state is managed. Done would require an agreed throttling state model, memory thresholds, recovery behavior, logging, and validation for transient pressure and suspected leaks.

Written by the indexing model from the issue text.