Investigate into a new way of calling discovery protocols from Discovery. This will only be done if it doesn't require changes to discovery implementations.

Flaws with the current approach

• Inherently synchronous; JGRP-2892 illustrated some of the issues when asynchronous discovery is used.
• 2 events FIND_INITIAL_MEMBERS and FIND_MBRS_ASYNC: there should be only one, which is inherently asynchronous
• The discovery protocol decides when a discovery is done Responses.done(); however, this should be decided by the caller (e.g. ClientGmsImpl.

Approach

• Caller sends down a FIND_MBRS event
• This is handled by Discovery.down(Event), which calls the various discovery protocols
• The call is void findMembers(List<Address> members, boolean initial_discovery, Responses rsps)
• An implementation adds its responses to rsps, or sends up (this is new) a FIND_MBRS_RSP containing one or more PingData elements
• The caller (e.g. ClientGmsImpl) handles either the FIND_MBRS_RSPS events (new), or the callback inside of Responses (which it previously installed).
• The caller decides when it has enough responses, e.g. (in ClientGmsImpl) when a JOIN_RSP was received. An attribute such as break_on_coord_rsp (in Discovery) therefore probably has to moved to GMS.