Make event queueing explicit

[FragLegs]

The SSF spec talks a lot about the moment that a Transmitter sends an event to a Receiver. However, that is not the only moment in the lifecycle of an event. An event's life goes through the following steps (wrt to SSF):

1. An event happens and is reported to the Transmitter
2. The Transmitter queues the event on zero or more streams
3. The Transmitter sends the event to the Receiver OR the Receiver polls the event from the Transmitter

The spec should make these steps more explicit because it will help to make sense of the stream status information. For instance, when a stream is enabled, all three of these steps happen. When a stream is paused it means that 1 and 2 still happen, but 3 is temporarily stopped. When a stream is disabled, only 1 happens - both 2 and 3 are ignored.

By connecting the stream status to these event creation and queueing moments, it will become easier to answer questions like, "What should happen to polling streams when the stream is paused?"

[ysarig75]

A related topic is event retention. There is an implicit assumption in the above description that a transmitter is expected to hold on to queued events when a stream is paused. The problem is that there is a practical limit on how many events a transmitter can hold and there is also a (performance, reliability, finance) cost associated with doing so even if the transmitter is able to hold the events. Some transmitters may choose to pass the cost of event retention to customers by providing them with options. Some transmitters may decide that they do not want to address the issue and chose not to retain events at all. It may be good to add some clarity about event retention in the spec in terms of expectations/configuration.