[10] Elastic Search Wrapper

We need to implement the Elastic Search to the UI.

This work issue is for implementing the base for connecting, identifying, verifying and quering such servers, much like how we do towards bitshares nodes today.

We have two different wrappers:
1. The ES Backend API on the server. *not in this scope*
2. Handling results in the UI by either of two ways
a. A Client ES Wrapper in UI, which handles connecting and results.
b. A Server ES Proxy Wrapper on the server, which handles connecting, routing and results. This would still require some updates and changes to the UI code, but probably less as the Proxy wrapper would return results in a similar fashion as the core node.

This Issue is for the second, client side, wrapper.

Work for this is roughly estimated, meaning that the assignee should report back if work takes longer/shorter time.

Assignee should work for a good base so issues in #1733 could be worked on

### Tasks
- [ ] Handle available ES API wrapper functions
- [ ] Connect to best ES API node
- [ ] Greacefully handle issues when nodes aren't responding properly.
1. Connect to next best node
2. Return on chain data instead

### Available API Nodes

URL|Maintainer|Notes
-|-|-
https://eswrapper.bitshares.eu/apidocs|@xeroc|-
http://bts-es.clockwork.gr:5000/apidocs|@clockworkgr|Missing SSL

----

As discussed in the Dev channels, and that I've understood from it, we do have two different ways to approach this. My initial idea was to have a client wrapper, but as noted we could also make a server proxy.

### Client Wrapper

### Server Proxy

Some notes from the chat, for further discussions
> with the Proxy approach, no need to modify UI for account histories so far. To add more advanced query features, implement at the proxy level, forward to ES or Node. The downside: people who connected to a non-ES node will be unable to use those queries, we need to expose this info on API node page. API node operators can forward ES queries to ES servers run by others though.

> With the ES wrapper approach, UI need new code to maintain 2 connections (although the HTTP connection to ES wrapper can be short-lifetime), and code for ES server pinging. UI need new code to query account histories from ES, also need to keep old code for fallback to node. To add more advanced query feature, still need code on proxy level. But users can choose different ES nodes / API nodes, say, can connect to a API node which is faster but doesn't run ES.

> For bitshares-ui, long-term strategy, I think the ES-wrapper approach is better, although need more code.

The issue names no files or tests. Start by reviewing the existing BitShares node connection and result-handling code, then resolve whether the client wrapper or server proxy is in scope. Done means the selected approach supports the listed wrapper functions, chooses an available node, and falls back when nodes fail.

Written by the indexing model from the issue text.