enable long interleaving mode for LR11x0 and SX128x

[Jorropo]

Using long interleaving is not a breaking change, the receiver node is able to use the lora header to know if LI encoding is used or not and will decode LI packets correctly.

However the problem is SX127x and other first generation LoRa IP which do not support LI at all, for theses it is a breaking change.

HOWEVER due to the sync word bug the LR11x0 already can't talk with SX127x, so if we enable LI on theses no one would be able to tell. Same for SX128x altho this is because it works on 2.4Ghz which is incompatible with SX127x.

[fifieldt]

This increases transmission time, yeah? How might this impact bandwidth and air utilization?

[Jorropo]

@fifieldt no infact it is sometimes shorter by one symbol (idk why).

This affect the order in which bits are transmitted.
With default lora a let's say WiFi Hallow packet collision during a TX would corrupt a couple bytes in let's say the center of the message.

However the FEC (Forward-Error-Correction) isn't great at correcting many corrupted close together bits.
With long interleaving bits are interleaved all along the message, so corrupting a couple adjacent bits "randomize" the indexes of the corrupted bits.

Which is easier to correct.

The only two downsides I see:

1. incompatibility with first generation LoRa IP (SX127X, ...) (this is why this PR only enables it for LR11X0 and SX128X which are already incompatible due to the sync word bug and <1Ghz != 2.4Ghz respectively)
2. it becomes impossible to stream the lora decoding, without LI it would in theory be possible to receive the meshtastic header, and before we receive the full packet decide if this is a packet we care about or not (there are many details like FEC and CRC making this non trivial). So in theory you could code something that sometimes saves battery by shutting down the RX for packets you know you don't care about.
   With Long Interleaving the bits are received in a random order, so handling packets before we fully receive them (which we do not do) become more questionable than it already is.

In other words: we should expect less CRC RX errors for LI packets in noisy and congested situations, particularly if you are using a high coding rate.

[NomDeTom]

I agree with this for now - it appears painless in the current iteration.