The e131 controller currently suppresses sending anything all but the first of a consecutive string of all zeros updates.  The original comment for the current behavior seems to suggest that we wanted to stop sending after 1 second of all zeros.  But I don't think its been working that way.  Jon C on the forum made the case that he was expecting us to keep sending in order to compensate for lost packets.

This change tweaks the all-zeros check such that it will output zeros once per second during a long stream of all-zeros updates.   Is this a good thing?
Merge remote-tracking branch 'remotes/sall/master' into e131zeros
This change set reworks the e131 packet suppression to work as follows:
-There are 2 values configured on a controller instance.  These values operate on each universe independently.
-EventRepeatCount specifies how many duplicate packets will be sent when the controller is receiving the same data over and over. 0 means send them all.
-EventSuppressCount only matters if repeat count is set. This specifies how many packets will be suppressed before one is let through anyway (kind of a keepalive).  0 means no keepalives.
-Both of these values default to 0 meaning we'll send all the data that comes to us (this is different from before now when the special case of zero data across all data would only be sent once).

The meat of this functionality is in the foreach universe loop of UpdateState.  The logic is basically:
-check to see if the current universe data is the different from the last one sent, if so, send it and reset the counters
-check if dup suppression is on and if we've sent the repeat count of dups, if not send this one.
-check if keepalives are enabled and if we've already suppress the suppress count of dups, if so override and send this one.

Something to think about for the next enhancement to this controller for environments where packet loss is a problem: Add a parameter that will cause the controller to repeat each packet N times.  I didn't include that this time because it would mean the hardware controllers would be hit with N packets in a row faster than they've ever seen... can't predict how they'd react.
Merge remote-tracking branch 'remotes/billlutton/e131zeros'

# By billlutton
# Via billlutton
* remotes/billlutton/e131zeros:
  This change set reworks the e131 packet suppression to work as follows: -There are 2 values configured on a controller instance.  These values operate on each universe independently. -EventRepeatCount specifies how many duplicate packets will be sent when the controller is receiving the same data over and over. 0 means send them all. -EventSuppressCount only matters if repeat count is set. This specifies how many packets will be suppressed before one is let through anyway (kind of a keepalive).  0 means no keepalives. -Both of these values default to 0 meaning we'll send all the data that comes to us (this is different from before now when the special case of zero data across all data would only be sent once).
  The e131 controller currently suppresses sending anything all but the first of a consecutive string of all zeros updates.  The original comment for the current behavior seems to suggest that we wanted to stop sending after 1 second of all zeros.  But I don't think its been working that way.  Jon C on the forum made the case that he was expecting us to keep sending in order to compensate for lost packets.
  Fix last fix for empty names from AddMultiple. Somehow this check ended up in the wrong place - dunno how I did that. This puts it in the right place. The way it is now, AddMultiple cannot be used. Should merge/push ASAP.
Merge branch 'e131zeros' into elementMoving