Drop oldest packet from radio when queue is full

[GUVWAF]

Potential fix for #5152.

It looks like the radio was enqueuing packets so quickly that the Router could not handle them fast enough. Then eventually the fromRadioQueue gets full, in which case the Router thread was never activated again because setReceivedMessage() wasn’t called. I now rewrote the logic such that it discards the oldest when it’s full and always notifies the Router to dequeue.
I tested it by faking that the queue is full, and it seems to work.

From the issue it looks like again the full e-ink refresh takes too much time (maybe in combination with MQTT proxy). This actually sounded quite familiar to what I’ve experienced once also with the T-Echo when I was in the big mesh in Vancouver, but I didn’t have serial logs then. @thebentern @caveman99 what about increasing MAX_RX_FROMRADIO from 4 to let’s say 8, to avoid dropping packets when the Router can’t handle them quickly enough? Or maybe only for devices with e-ink screens?

[thebentern]

Looks good to me. The MAX_RX_FROMRADIO increase sounds good. We'll have to take another look at memory footprint on the different platforms after that increase.

[GUVWAF]

After a second look at the logs it really looks like it was caused due to a couple MQTT proxy packets received back-to-back during a full e-ink refresh. I actually don't think it's worth increasing it since this would normally not happen via LoRa.