Fix context chain initialization and SLAVE change

Fix context chain initialization and SLAVE change

- Merge ContextChain and LifecycleService
- Let ClusterSingletonService handle stopping of mastership services in
closeServiceInstance method
- Store cluster singleton initialization future and process it
synchronously in case we are closing
- Cancel device initialization future if we got timeout
- Handle initialization chain order in ContextChain instead of storing
each next phase in contexts
- Remove SLAVE task from scheduler in case we acquired SLAVE role
already
- Prevent adding exactly same auxiliary connection twice to list of
auxiliary connections in ContextChain
- When SLAVE role is obtained from cluster singleton service, notify
MastershipChangeListener about it
- Log exceptions from handshake as warning instead of error (as only
problem is that device gets disconnected and reconnected, what is not
critical)
- In case context chain is still closing and we receive new connection,
drop the connection and let context chain finish closing

See also: bug 8805

Change-Id: If14da19899087018c5e6cc42d195af43c1e89bfd
Signed-off-by: Tomas Slusny <tomas.slusny@pantheon.tech>