495 build uap for client

[BartolomeyKant]

closes #495
The main idea:
We have ConnectivityPolicy for each client instead of common UAP.
ConnectivityPolicy answers the questions:
When next rx request should be performed and is it possible or not suspend right now.

User configures rx timings {interval, rx_window} for each server priority on client's cloud.
Based on this timings ServerPings are created to perform actual ping requests. On each request next rx time point is saved among record time. This values are stored on persistent memory. If current time is less than next rx time point ServerPing waits till time for next rx. If current time is less than record time it means clock was reset and we need to reset all saved times to.

Sleep/work cycles are full responsibility for user's busyness logic.
While ConnectivityPolicy track only rx timings, user can track TX timings by its own.
Workflow:

• at first cycle run both RX and TX than choose min(next_tx_time, next_rx_time) and deep sleep
• on wake make either TX or RX
  • if TX only send message and save next tx time
  • if RX create message stream to receive messages and wait till can_suspend comes true. Then select min(next_tx_time, next_rx_time) and deep sleep.