Fuzzy Paths: a new "wide" path mode for potentially better reliability on retries

[redxdev]

See #2487 for my original proposal. I've gone back and forth on whether this should be called fuzzy/wide/thick or something else, happy to rename. Also, consider this a proof of concept as there's a bit of unfinished work and I'm not even entirely sure this is a good idea, but I wanted to try my hand at it nonetheless.

This implements a new method of pathing that is in-between a direct path and flood routing. If requested, updated repeaters can repeat a packet that was intended for a neighboring repeater, effectively "widening" the path. Flagging a path as "fuzzy" is done by appending an FF prefix (or FFFF, or FFFFFF depending on hash size) at the end of a path to signify that fuzzy repeating is allowed.

Some notes about compatibility, additional work, etc:

• Fuzzy paths are opt-in from the sender. This does not affect the behavior of normal direct-path packets or flood routing - it only affects packets that have explicitly added FF at the end of their path.
• I'm unsure if flagging a fuzzy path by appending FF to it is the best way to go - it was the easiest backwards-compatible method I could think of since as far as I can tell FF is reserved but not actually used, and the only downside is losing a single hop if a fuzzy path is used.
• Old repeater firmware will continue to repeat packets with fuzzy paths the way they would normally, they just won't repeat for neighbors like the updated firmware will.
• The recipient of a packet with fuzzy pathing must be on updated firmware as recipients will otherwise ignore a packet meant for them, because they believe that repeater FF must first see the packet.
• The sender does NOT need to be on updated firmware since the flag for a fuzzy path looks like a normal repeater with an invalid prefix.
• I'm not sure if room servers have repeat logic (I didn't look into them too much) but they could automatically fall back to a fuzzy path as an attempt as well.
• For debugging/packet logging purposes I've changed the route type to Z for fuzzy paths since F already means flood.
• I have not done any work on making anything configurable yet, though I've left a few TODOs in MyMesh::isNextHopNeighbor about it. Right now any neighbor with an snr >= 0 will be considered when deciding whether to repeat for a fuzzy packet.
• I have done limited testing across a few devices (heltec v4 with updated firmware on the receiving end, an r1 neo without updated firmware as the sender, and a T1000e with updated firmware as a repeater).
• One downside of using a fuzzy path is that you can't know the true path that a packet took. Fixing that would require effectively rewriting how paths work for this mode and breaking any kind of compatibility for this type of path, which I did not want to do. As such, I would say that fuzzy paths are intended as a sort of last resort before the real last resort of flooding.

My idea is that this would be used as a fallback after attempting a couple of direct messages but before trying a flood message, since this should be much cheaper and potentially has a higher likelihood of reaching its destination if a repeater is busy. This will require app support since as far as I can tell the firmware does not decide how to handle retries, but I am not entirely sure the best way to go about adding that support. As things are with this PR now, an app would need to update the contact's path to have FF for the message it wants to retry, but ideally it'd be able to set a flag via the companion protocol. I was not comfortable changing that as I'm unsure how to handle that in a backwards compatible way, especially since no apps actually support this yet.

[redxdev]

Something I did want to mention regarding the main downside (it not being possible to understand the true path in fuzzy mode): I do have what is I think a clever solution. To be clear, this is not implemented in this PR, it's much more complicated and harder to make backwards compatible even if it is technically "better", and I didn't want to put in the work without further discussion. With that out of the way...

First: instead of each repeater removing itself from the path as they repeat, the full path is left in place in fuzzy mode, sort of like a flood packet. This means a bigger packet (which is the main downside aside from compatibility), but will allow us to fully capture the path the packet takes.

Second: instead of the FF marker placed at the end of the path, it is placed at the start and then gets moved every time a repeater repeats the packet. For example, the initial packet might have a path of FF,A,B,C. When repeater A repeats it, it'll change the path to A,FF,B,C. If a neighboring repeater picks up the packet (let's say D is a neighbor to A) then it'd change the packet to D,FF,B,C. This allows tracking how far into the path the packet has made it which has two benefits:

1. We can see an obvious split between the path that we know the packet has traveled and the path we want it to travel.
2. Repeaters can avoid repeating for any neighboring prefixes that come before the FF in the path, since those are already known to have been handled by a prior repeater. This stops an issue where a fuzzy packet could end up acting like a flood packet (which is specific to using the full path and not something that can happen in the current PR).

[ripplebiz]

Very interesting idea. I also thought moving the FF like a cursor is the better idea.
But, this very thing is why the 00 and FF prefixes were reserved--for some future encoding tricks.
I'll have more of a think on this one, and if there are edge cases or possible unwanted side effects we'd need to mitigate.