Bug 4105: Remove candidates on PeerDown

Bug 4105: Remove candidates on PeerDown

Currently on PeerDown, the EntityOwnershipShard selects a new owner for
the entities owned by the down node and leaves the down node as a
candidate. If the down node is the only candidate, the owner is cleared.
On PeerUp, it selects a new owner for those entities whose owner is clear.
This was done to handle network partition so a node's candidates remain
registered and are re-assigned when the partition is healed.

Howver this has potential issues when a node is actually
stopped/restarted. It's possible, on restart, that the node doesn't
register a candidate for an entity that it had previously registered for.
So it may get ownership of an entity for which it has no registered
candidate.

To alleviate this, I changed it to remove all the down node's candidates
on PeerDown. If the node was stopped/restarted, then it will
re-register candidates based on local client requests. This case will be
the norm. To handle network partition, when healed, the follower node
will get the replicated commits for its candidate removals from the
leader. So on Candidate removed, it re-adds its removed candidate if it
has a registered EntityOwnershipCandidate.

I realized that one can register a DOMDataTreeChangeListener for a leaf
node. So I simplified EntityOwnerChangeListener to listen for the owner
leaf instead of the entity path. This avoids the extra notifications
when candidayes are added/removed. I actually did this originally b/c I
thought there was a bug when listening at the entity level which turned
out there wasn't but I left it in as an improvement.

I also added the shard's logId to the listener and support classes for
better debugging of unit tests.

Change-Id: I75d2567ce54b9129eee052ba521c8a71777289b6
Signed-off-by: Tom Pantelis <tpanteli@brocade.com>