First, create a new git branch from this one, and name it p2p, change to the p2p branch.

Add an option to wsssh and wsscp: --tunnel, in the config file is tunnel as well. The tunnel option accept a value or a series of values as value1,value2  that is the transport type for the data channel, or any to intend tunnel data channel autoselection.

Add a second option in wsssh and wssscp, --tunnel-control, in the config file tunnel-control. The tunnel control like the tunnel option accept a value or a serie of values as value1,value2 etc, values are the transport type for the control channel, or "any" to intend tunnel control channel autoselection.

Add a third option in wsssh and wssscp, --service, service in the control file as well, default ssh. This will be just any string up to a lemght of 255 chars long. this will be just passed to the server how described later  

A transport type is the connection we use to encapsulate a tunnel data channel and/or a tunnel control channel, like websocket.

A transport have a property, is_relay, if it is true the transport CAN encapsulate the control channel and/or the data channel, if it's false, it can encapsulate only the data channel.

A transport have another property, weight, max weight is 0, the higher the numnber the lower the weight.

A data channel is a channel where the tunnel_data message goes trough, while the control channel is the channel for all the other messages.


the option --tunnel will accept all the transport and the value "any", the option --tunnel-control will accept only the transports with property is_relay set as true, or the value "any".


I this moment we implement only one transport, websocket, it is a transport with is_relay set as true, in the --tunnel and --tunnel-control is named websocket. 

Other tunnels will reutilize as much as possible the exixting framing code, and essentially they will all use the same json message for the tunnel data, while all the other messages will remain on the control channel passing on the websocket on wssshd.

When wsssh and wsscp request to open a tunnel, it will try to connect to the wssshd server first using the --tunnel-control with the lower weight, and if connection fails 3 time try to escalate to the second lower weight and so on up to the higher weight, selecting only the tunnel-control transports indicate in the value list or selecting them all if specified any. The default behaviour is any

After connected successfully, it will send a tunnel request message, indicating to wssshd in the json request also the tunnel and tunnel-control, in both cases if any is selected send the list of all transports for tunnel and tunnel-control, , the --service option, anda property tool_private_ip with value the autodetected local IP address. 

in wssshd, in the tunnel status object, remove tunneltype attribute, add tunnel and tunnel-control reflecting the --tunnel and --tunnel-control options of wsssh and wsscp, rename the attribute src_private_ip to tool_private_ip, src_public_ip with tool_public_ip, src_public_port with tool_public_port, src_private_port with tool_public_port , and all the dst_*_ip and dst_*_port with wssshc_
Correct the tunnel messages to accept the properties passed by wsssh/wsscp at tunnel requests, and use to set the tunnel status object attributes.
When the request arrivem  set the attributes wssshc_public_* and tool_public_* using the ip and port from which wssshc and wsssh/wsscp are connected to wssshd and they sent the tunnel request.

Then wssshd send to wsssh/wssscp the reqyest to try to open the connection for the data channel using the transport with lower weight and wait for the wsssh/wssscp to reply. if the connection is established and tunnel is ready, set the status of the tunnel to "ACTIVE", if the data connection failed pass to the next lower weight if any, continue until you don't have other option, then ask to maintain the data channel on the same transport where the control channel, the one you are messagging on, is.

wsssh/wsscp after sending the tunnel request, wait for the reply with the indication of which data channel to open. If the reply doesn't arrive after a timeout of 5 seconds, or if the reply is the same channel as we are communicating the control messages, it will just reuse the same channel also as data channel.

also wssshc will implement --tunnel and --tunnel-control, but it will send them in the registration requests as well as the wssshd_private_ip.
wssshc will select the control channel at connection exactly as wsssh and wsscp do.
wssshd should be ready to handle this as well, and use those property to set the tunnel status objects.

for the moment there aren't any other transport but websocket, we are preparing all the structures and code needed to  add new transports later 

wssshc should handle correctly also the full message to open a tunnel, 
