Support proper data collection for multiple sensors per monitored segment

[dspruell]

Current event logic for tracking dispatched/received/rate on monitored segments works when a single sensor (say, a Suricata box) is monitoring the segment. But in cases where multiple sensors monitor traffic for a segment, or when a packet crosses other monitored segments en route to the target segment, multiple copies of the probe packet will be picked up by deployed monitors and reported to the manager, leading to an imbalance in dispatched/received events (one dispatched probe will be reported by multiple monitors).

Possible solutions:

1. Configure multiple monitored segments per physical network segment, corresponding to each sensor that should report an event for the segment. For example, instead of monitoring DMZ, segments could be set up for DMZ-Suricata and DMZ-Bro.
2. Introduce differentiator per segment:
   2a. One option is to modify each monitored segment to use different Probe Generators (e.g. multiple instances running on different ports) that are configured to use distinct payloads per monitored segment. ampt-generator would have to be modified to support multiple instances on different ports and config options per instance allowing to override the payload in the signature.
   2b. Another option is to modify each monitored segment to specify unique probe destination ports for the Probe Generators to use when crafting packets. This would additionally require introducing a configuration option per ampt-monitor likely at the plugin level) to specify the destination port that monitor will send events for. In this way, the event monitors will handle their respective probes but ignore probes intended for other sensors on the same physical segment (but corresponding to different Monitored Segments in ampt-manager).
3. Potentially modify ampt-manager so that per-segment stats are tracked, but that a concept of a segment group exists and some aggregate view of the health of the segment relative to all sensor segments can be viewed.

[dspruell]

Another idea: allow defining within the MonitoredSegment a count of sensors that should report for the segment. Could alternately assign/associate EventMonitors to segments.

For example, there is a segment, LAN. There are 2 Event Monitors, IDs 1 (Suricata sensor) and 2 (Bro sensor). Event Monitors 1 and 2 could be associated to the LAN segment. If a dispatched health check probe results in a ReceivedLog for both of those monitors, then that is a healthy state. If one is received, then that is a partially healthy state and if none received, then that is an unhealthy state for the segment. It might be necessary to implement a state for the segment we don't have yet (partially healthy) to reflect when 1 or more (but not all) of the associated monitors send logs for the dispatched probe. It would also be possible to see which monitors did not send a log, possibly pointing to problem sensor(s) for the segment.