Make ProxyServer sensitive to non-RouteFound Node states

[dnwiebe]

Sometimes, the Node will be up and running, but it cannot provide connectivity over the MASQ Network to exit Nodes and the servers beyond.

An example of such a state would be when the Node has just started up, but has not yet Gossipped its way to a neighborhood patch big enough to satisfy the current min-hops requirement.

Another might be when the Node has been started, but no wallet information has been set, so it's impossible to create CORES packages containing ClientRequestPayload_XvX messages.

Currently, when the Node is in one of these situations, and the browser (or other client) tries to transmit data over the MASQ Network, the ProxyServer accepts the connection and the request data, tries to send it, produces an error (which is logged), and then throws away the data and gives up. In this case, the browser thinks the request has been sent, and is left to time out waiting for a response, which is a bad user experience.

Tasks:
Make the ProxyServer sensitive to situations where the Node can't handle traffic yet. When the client tries to make a TCP connection in such a state, have the ProxyServer refuse the connection with a standard TCP error code, and send a message to the UIGateway with a user-friendly explanation of why the client connection was just refused, so that the UIGateway can broadcast this message to all UIs.

When the Node does come fully online, the ProxyServer should receive a message that switches it into operation, so that it accepts TCP connections and handles them normally.

Suggestions:

• Some standard TCP error codes to choose from: NetworkDown, NotConnected, ConnectionAborted, NetworkUnreachable, ConnectionRefused.
• Maybe the reason the Node can't be used right this minute could be passed into the ProxyServer in its constructor, and it could always begin by refusing connections for that reason--since the Node is never instantly available for traffic. However, we'll need it to be able to change its reason in real time: imagine a situation where the user can't connect first because he has no wallets, and then once he establishes wallets, he still can't connect because the neighbor Node he specified doesn't have any neighbors of its own. Whatever mechanism is used for changing the reason in real time could probably also be used for eliminating the reason, once the Node is fully connected and ready for traffic.
• So far we've talked only about situations where the ProxyServer can't serve when the Node starts up, and then can serve until the Node goes down; but there are also situations where it can't serve, then can serve for awhile, then can't serve again--for example, if its only neighbor goes down. In this case, we need to have a plan for what to do about browser connections that are already in existence at the moment service becomes unavailable.