[Feature] Allow repeater firmware to bridge over USB and IP

[hickey]

This PR adds support for bridging packets over USB serial and TCP connections in the same manner as the RS232 bridging works. It uses the same encoding as the RS232 bridge code.

USB serial bridge code is enabled with defining WITH_USB_SERIAL_BRIDGE and setting the serial stream by defining USB_SERIAL_STREAM (usually to Serial). Defining the stream in theory should allow the bridging output to be directed to a second USB port if the platform has another USB connection; although I do not have a solid way to test this configuration with the hardware available to me.

TCP bridge code is enable by defining WITH_TCP_BRIDGE. The port that the repeater will listen on is defined by TCP_BRIDGE_PORTand will default to 4403 if not specified. As a result when using the TCP bridge code the WIFI credential definitions need to be specified also in the build.

I have added build environments for the lilygo_tbeam_SX1262 named Tbeam_SX1262_repeater_bridge_usbserial and Tbeam_SX1262_repeater_bridge_wifi to demonstrate how the firmwares can be built. These environments should be able to be transported to other platforms that have compatible hardware.

In addition, I have added the usbserial and tcp bridge types to the get bridge.type CLI command. I am not certain if this will have any effects on the remote management in the companion app. There is nothing I see that is obvious. I have also updated the CLI documentation to note the values that can be returned by get bridge.type.

Closes: #3028

[ripplebiz]

Similar here, as with MQTT. We aren't going to officially support internet bridges.

[hickey]

But you do already indirectly and the precedence has been set. By officially supporting bridging over RS232 you have enabled opening the MeshCore network to other networks. This work just builds on that foundation.

[hickey]

And further thinking about your response and the immediate shutdown of any discussion just clearly shows the true intention of keeping MeshCore a closed community. There are lots of references out there that promote MeshCore as an open community but you are definitely showing the indications that this is just marketing spin and that you don't want to look at new use cases.

Too bad for the community.

[recrof]

open community

Open community doesn't mean we are open to any changes without limits. Allowing easy IP bridging means that the community will need to deal with irresponsible users, who will cluelessly merge meshes data over internet. There is no really stopping it happening, however we'll die trying. There is precedence in this on other mesh network, their MQTT bridges caused lot of headaches for mesh communities and actual devs. We won't repeat that.

[hickey]

@recrof Your definitions are completely wrong. Open community has nothing to do with code changes. Open community has everything to do with discussions and listening to ideas from diverse perspectives.

That simply was not the case here and it was a complete shutdown.

BTW, this PR has nothing to do with the MQTT PR (#3030) that I produced.

[recrof]

BTW, this PR has nothing to do with the MQTT PR (#3030) that I produced.

the idea is the same. our stance is clear: no internet downlinks.