This replaces the per-participant timed-event for periodically
broadcasting its SPDP message by a central device that schedules and
sends the SPDP messages for all participants and maintains the set of
addresses to which to send them.

There are a number of benefits to this model:

* We can make it more likely (certain, if we want) that SPDP messages to
  a single destination go out in a single packet, reducing the packet rate
  if there are many participants.

* We are no longer dependent on an "addrset" for tracking the set of
  addresses to publish to (and we don't need to special-case SPDP
  writers). That means we now have the option of "aging" locators and
  lowering the frequency or giving up on them altogether if there just
  doesn't seem to be anything at that address.

This eliminates looking up the SPDP sample in the WHC, which became rather painful with
the introduction of serdata_plist, and eliminates the problem of the dispose+unregister
not getting stored in the WHC (removed from the index, best-effort so not retained until
ACKs come in).

It also solves having to construct an address set based on the addresses in the SPDP
administration and patching that into the SPDP writer, which was a horrible hack to begin
with.

The old default of 9 (so 10 participants) was hit rather often.  This raises the default
to 99 (so 100 participants).  The only real downside is that increases the number of SPDP
packets 10x if unicast discovery is used.

Signed-off-by: Erik Boasson <[email protected]>

If one adds a host to the peer list, we add MaxAutoParticipantIndex+1 locators for it, but
it generally doesn't make much sense to keep pinging all of them if there is no response.
Especially if MaxAutoParticipantIndex is large, it causes a lot of periodic traffic.

SPDP locators can be added by the configuration but also by discovering a peer that
we (presumably) cannot reach via multicast.  The question is what to do with such a
discovered address when the peer is no longer there.

If we learnt a locator through discovery and we know for certain that the peer is no
longer there (i.e., received a dispose/unregister) and that there are also no other peers
at the locator, it makes sense to remove the address: a new peer that shows up at that
locator would presumably try to contact us.  If instead the peer's lease expired, we need
to keep pinging it for a some time in case it was just the disconnect.

So for each SPDP locator we need to know why we have it in the table of addreses.

Signed-off-by: Erik Boasson <[email protected]>

This replaces the somewhat silly (and ancient) tracing of the queue length on every
insert.

Signed-off-by: Erik Boasson <[email protected]>

Signed-off-by: Erik Boasson <[email protected]>

Signed-off-by: Erik Boasson <[email protected]>

Replaces src/core/xtests/spdp_scenarios.bash