IMPALA-1178: fix Impalad crashes during query cancellation

There are several variants of races that can occur if a query is unregistered
or cancelled before it's fully running.  Normally, this will only happen when
the session or connection is closed, because the 16-byte query-id won't yet be
available to a client to cancel/close the specific query until after
ExecuteStatement and friends have returned the query_id.  However, it could
also be triggered via the web interface or if a user were able to "guess" the
query-id before it's returned by ExecuteStatement (e.g. by scraping the web
interface where queries show up "early", though for HS2 could implement secret
to prevent that).

Here's some examples of the race (the first leads to the DCHECK reported in
the jira).

* If session is closed and query unregistered before exec_state->WaitAsync()
  completes, then the async thread would be freed while still executing.
* If the query is cancelled before coord_ is set, then exec_state->Cancel()
  won't be effective.
* If Coordinator::Cancel() is called before executor_ is set, then fragment
  cancel won't be effective.
* Lot's of other points with inconsistent state (but not safe to hold the
  lock) where correctness is hard to reason about.

The session->inflight_queries already tracks which queries to unregister when
a session is closed.  Delay adding queries to this set until after it is safe
to cancel.  This handles the session/connection close case.

Then, add a boolean arguement to UnregisterQuery and CancelInteral that
indicates whether these should return error if the query is not yet in-flight.
When UnregisterQuery() is used to clean up after an error on the query issue
path (when the query is not yet in-filght) will pass false.  Otherwise, the
other paths will pass true, and this in-flight check will guard against the
race from the CancelOperation RPC path.

Also, fix a race in query expiration.  Previously queries could be processed
by ExpireSessions() before last_active_time_ was set (though in practice it'd
be hard to hit this race because timeouts are specified in seconds) and before
it's safe to cancel.

Testing:
- verified this fixes the crashes/hangs using the steps to reproduce given in
  IMPALA-1178.
- Attempted to add a pytest case for this but so far I've had no luck
  reproducing it programmatically.  Will try some more and follow up with a
  separate change when that's successful.

Change-Id: Iec6b977e28fbec2d8bcc2734d1b7c17604e44180
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/4245
Reviewed-by: Daniel Hecht <dhecht@cloudera.com>
Tested-by: jenkins