Improve acceptance criteria of end-to-end test

[gavv]

TestEnd2End_Default is a simple test that works as follows:

• creates sender and receiver, and connects sender to receiver
• in the first goroutine, repeatedly writes samples to sender
• in the second goroutine, repeatedly reads samples from receiver
• waits until it receives two consecutive non-zero samples and exits

This algorithm is the most basic check that verifies that if we send "something", then we eventually receiver "something", with a very relaxed definition of "something" (two non-zero samples).

---

It was implemented like this because we can't implement very strict check: we can't rely that we receive the exact same stream as we send.

When resampler and other processing is disabled, a few differences are possible between sent and received streams:

• received stream can produce arbitrary amount of zero samples before it starts producing the original stream
• arbitrary chunks of original stream may be replaced with zeros in received stream
• frame boundaries are not preserved; the first frame written to the sender may start in the middle of the first non-zero frame read from receiver

---

Keeping this in mind, we can improve TestEnd2End: make the check more strict and meaningful than it is currently, though relaxed enough to take into account possible stream modifications described above.

Here is an algorithm that we could implement in the test:

• on sender, produce a repeating sequence of incrementing numbers 0 1 2 ... 99 100 0 1 2 ...; we can use this sequency for L channel and the same but negated sequence for R channel

• on receiver:

  • wait until we receive first non-zero sample

  • check that since then, each sample either have expected value (so that the next sample is previous sample plus one), or is zero (if corresponding packet was lost)

  • also check that either L = -R or L = R = 0

  • wait until we accumulate 10'000 non-zero samples in total (not taking into account possible zero samples)

• both on sender and receiver, we should limit the speed of invocation of WriteFloats and ReadFloats methods

  For example, if sample rate in sender/receiver config is 44100, we should try to write and read only 44100 samples per seconds; e.g., if our frame size is 100, then we should write frame each 1/441 = 0.002267 seconds.

  We can create tickers for both sender and receiver with corresponding frequency and wait a message from ticker before invoking write or read next time.