Breaks the cycle where reporting low memory can trigger more reporting

[vector76]

Reporting low memory via log_warn() consumes some heap. A decrease in heap can trigger another low memory message. This can run away and produce a burst of low memory messages that consume a lot more memory than necessary.

This causes the overall system to be more sensitive to low memory conditions because the warnings can chew up the last bit of memory at the worst time.

Through separate testing I found that channel->write() on a websocket temporarily consumes about 1.5k. Writing to a uart is much less.

This PR keeps track of a separate "true" memory low watermark and "last-reported" low watermark and delays (200 ms) reporting if the true low watermark is not too much (< 2k) below the last reported low watermark. This breaks the runaway cycle of messages triggering more low-watermark events. The true low watermark is still reported eventually (up to 200ms late), and larger drops in heap are not subject to the delay, in case the system is about to become nonresponsive.

I tested this with a modified build that deliberately leaks memory on command. With the system idle, depleting the memory 1k at a time eventually triggered a long burst of Low memory warnings that consumed the rest of the memory. With the delay in place to break the cycle, only two messages were generated and very little extra memory was consumed by the messages.