Add Sentinel change notification handling logic

Add Sentinel change notification handling logic

When new Redis master has been promoted, Sentinel publishes
notification to '+switch-master' channel.

Refer to below web page for further details:
https://redis.io/topics/sentinel

'AsyncSentinelDatabaseDiscovery' will now subscribe notifications for
above mentioned channel. Notification contains information of new Redis
master, which is parsed from message and sent to upper layer via
'StateChangedCb' callback (if callback is set).

When notifications are subscribed from Redis (from Sentinel this case),
connection will go to "subscribed state", and only some pub/sub related
commands are allowed.

Due the above reason, we have two connections (command dispatchers).
One to subscribe notifications and the other for Sentinel commands,
like master inquiry.

Refer to below web page for further details:
https://redis.io/topics/pubsub

In case that subscriber connection goes down, subscription for
notifications is renewed once connection to Sentinel is working again.
Extra master inquiry will be made because we might be missed
notifications during connection cut. Latest master address is refreshed
via 'StateChangedCb', even if has not changed compared to last informed
address. This could be optimized, but as being very rare situation
was not seen worth of extra logic.

In case that the other connection (used for Sentinel commands) is cut,
the related command dispatcher will re-connect in the background.
Possible Sentinel commands during connection cut will fail and trigger
retry after short delay (per already existing implementation).

If some notifications are missed due some other reason than connection
cut, SDL might go to the state that operations will made to Redis slave.
In this situation write operations will fail with a new internal
'AsyncRedisCommandDispatcherErrorCode::WRITING_TO_SLAVE' error code,
which is mapped to 'shareddatalayer::Error::BACKEND_FAILURE'. Recovery
instructions adjusted a bit, so that re-creating SDL API instance is
not optional recovery step (it is the only way to recover from above
mentioned situation currently).

Sentinel support is still disabled, missing implementation will be
added soon as a separate commit(s).

Signed-off-by: Rolf Badorek <rolf.badorek@nokia.com>
Change-Id: I1bb9e121985ee22278e780e50ab13f88acdc65c5