TODO: websockets-transport
 Предлагается следующее решение:

 - Пир стартует и пингует/получает PEX по UDP - это, вроде бы, работает.

 - Пир получает расширенную информацию о пирах --- например, путем запроса
   ссылки или еще как-то (TBD), что бы не делать лишний протокол.

 - В отдельном потоке пир поднимает сервер

 - Сервер ведёт список список клиентов, ключом является публичный ключ
   (либо же нонс - лучше нонс)

 - Сервер ждёт соединений и трекает их в общем каком-то стейте

 - Возможно, поднимает "пира" и использует те же самые команды,
   правда в нашем случае только GetBlockChunks, используя в качестве
   транспорта реаилзацию WS

 - Через какое-то время после старта сервера, пир пытается поднимать
   треды с ws - клиентами. Один клиент -- один пир. Проверяет, если
   соединение уже установлено с сервером - то запрашивает трубу для того
   соединения. "Труба" -- это реализация пира через какой-нибудь TChan
   для уже имеющегося соединения.

 - Если соединения нет, то пытается поднять соединение со стороны
   клиента

  Логика работы через WS существенно другая, полагаем, что пиры
  изначально связываются по UDP/Ping/PEX.

  Однако, в дальнейшем можно и бутстрап и всё прочее делать,
  указывая префикс протокола ( ws://xxxx или udp:/xxxx ) в
  URI пиров.

  На каждого пира запускается свой поток скачивания, аналогично
  UDP.  Потоки отгнивают, если теряется авторизация (?), все
  такое же.

  Таким образом, WS пир это или тред вокруг websocket-клиента,
  либо же тред вокруг трубы, торчащей из вебсокет-сервера.

  Является ли проблемой, если получится одновременно установить
  и клиентское, и серверное соединение?

  Надо бы понять. Возможно, ничего специально делать не надо,
  будет две трубы - да и пусть себе.

  TBD: udp-relay
  TBD: ws-relay