4351cda Add current_params_root key to getblockchaininfo (Steven Roose)

Pull request description:

  backport of #799

Tree-SHA512: 191982c3b12696c9f704c8780099ae2e27e1b8d4468a8a4b6d82cdc4c583c20f6d50cbabb21b4d300f7f94248b731ad8fabaa7b1d592b391dd27771985abf00e

…tdown

b7aa717 refactor: gui, simplify boost signals disconnection (furszy)
f3a612f gui: guard accessing a nullptr 'clientModel' (furszy)

Pull request description:

  Fixing ElementsProject#800.

  During shutdown, already queue events dispatched from the backend such
  'numConnectionsChanged' and 0networkActiveChanged' could try to access
  the clientModel object, which might not exist because we manually delete
  it inside 'BitcoinApplication::requestShutdown()'.

  This happen because boost does not clears the queued events when they arise
  concurrently with the signal disconnection (see https://www.boost.org/doc/libs/1_55_0/doc/html/signals2/thread-safety.html).
  From the docs:
  1) "Note that since we unlock the connection's mutex before executing its associated slot, it is possible a slot will still be executing after it has been disconnected by a [connection::disconnect](https://www.boost.org/doc/libs/1_55_0/doc/html/boost/signals2/connection.html#idp89761576-bb)(), if the disconnect was called concurrently with signal invocation."
  2)  "The fact that concurrent signal invocations use the same combiner object means you need to insure any custom combiner you write is thread-safe"

  So, we need to guard `clientModel` before accessing it at the handler side.

ACKs for top commit:
  hebasto:
    re-ACK b7aa717

Tree-SHA512: f1a21d69248628f6a13556a9438c9e4ea9f0a3678aab09ddfe836e78e4eee405a6730d37d39f1445068ada3a110b655b619cf0e090fc2d0cdf99bed061364aeb