Take Impala offline if local Node Manager can't be reached.

When RM is enabled, the local Node Manager is very important in handing
out resources to its Impalad counterpart. If the NM goes offline,
therefore, no resources can be acquired and there's no way to run a new
query. This patch adds a failure detection thread to ImpalaServer which,
every 2s, tries to open a connection to the NM. If it fails for five
consecutive attempts, the NM is considered down, and Impala goes into a
new 'offline mode'.

When offline, queries will be rejected either before their query exec
state is registered, or after they exit admission control (on the basis
that users would prefer quick feedback at the expense of waiting for
their query to exit admission control and hoping that the NM comes back
up in that time).

Also when offline, Impala removes itself from the global backends list
sent to the statestore, which prevents any further queries from being
scheduled here. Queries that are already in flight are allowed to run,
as they may already have their resources and might be able to make
progress.

CM provides a full URL for the new local_nodemanager_url flag, in case
we want to scrape the page at any time. For now, we use our simplistic
socket cnxn mechanism to decide if there's a failure (and so there could
be false positives if another process takes the port; this would usually
indicate a CM configuration error).

The existing metric impala-server.ready is set to 0 when Impala is
offline.

Change-Id: I3df918bfc674472625336cabe69cf5cf2c073308
Reviewed-on: http://gerrit.ent.cloudera.com:8080/1801
Reviewed-by: Henry Robinson <henry@cloudera.com>
Tested-by: jenkins
Reviewed-on: http://gerrit.ent.cloudera.com:8080/1785
Add memory and VCPU expansion to RM-enabled queries

* Each node has one QueryResourceMgr per query it is running fragments
  for. A QueryResourceMgr handles creating expansion RPC requests, and
  monitoring the thread:VCPU ratio for each query (and requesting more
  VCPUs from YARN if oversubscribed).
* MemTrackers now have an ExpandLimit API which does nothing unless they
  have a QueryResourceMgr. This method blocks for now, but when the IO
  manager changes its API to use TryConsume(), we'll need to issue these
  asynchronously to avoid keeping hold of a thread.
* ResourceBroker etc. got updated to support the Expansion API.

Change-Id: Ia3c4635497f0563cfc5cd0e330e5f1f586577200
Reviewed-on: http://gerrit.ent.cloudera.com:8080/1800
Reviewed-by: Henry Robinson <henry@cloudera.com>
Tested-by: jenkins
Reviewed-on: http://gerrit.ent.cloudera.com:8080/1748