Show nodes we have not yet received a NodeInfo from.

[armooo]

We will receive random packets from nodes with a marginal connection but often will never get a NodeInfo. The connection notification will then show more nodes online that are visible in the node list. This fixes #912.

I decided to give the unknown nodes the name "UNK: !". This matches what was already being done in the chat view where only the hex id is used. It was also somewhat simpler because the to and from fields on DataPacket already had this format.

[CLAassistant]

All committers have signed the CLA.

[prokrypt]

Nice! Does this also make position packets from those nodes appear on the map?

[armooo]

I expect it should. The map and the contacts list both use model.nodeDB.nodes which is populated now due to calling installNodeDB and upsert with userless nodes in MeshService. I will see if I can get my node to broadcast a location before I get a NodeInfo from it to confirm.

[armooo]

Good call on testing the map view, there was a node.user!! hiding in it.

[prokrypt]

Possible bug somewhere: only one UNK shows on the map (possibly the latest one). Or maybe it's something I did. hmm. I have 11 nodes with coordinates and 3 of them are UNK. Logcat shows Showing on map: 9 nodes 0 waypoints

Bug number 2: unknown nodes can't be searched

Bug number 3: long-pressing node on map jumps to wrong node in list, maybe.

[armooo]

Sure I can give synthesizing a MeshUser a shot and see how that works out.

also unknown_username_node_id seems a bit redundant as the unknown shortname/longname res strings can be used.

I was thinking we would want to keep the string concatenation in the template for RTL languages if the translator wanted to localize and UNK and move in the string.

[noon92]

Thanks for thinking of RTL languages.

[armooo]

your approach looks good overall, but instead of doing work on the UI side, consider adding a default user when a new NodeInfo DB entry is created in MeshService.

This mostly worked but in cases like a resetting the NodeDB you can still have messages referencing nodes which will not exist. I added an infallible getNode method to the model.NodeDB as well which will make a NodeInfo if once can not be found.