Fix the ClientLatency acceptance test (LP: #1491876) (LP: #1447947)

There were multiple problems:
  * Samples where latency was actually nbuffers were incorrectly recorded
    as a latency of zero because the old code did not account for the
    fact that we might have record of the same buffer_id twice before
    the compositor has cleared out the old instance. All due to the
    "early release optimization".
  * The simulated compositor was not sleeping at all, so did not
    realistically allow the client to get ahead of it to fill the
    buffer queue, hence creating spuriously low latency measurements,
    which finally explains LP: #1447947.
  * The final average measurement was calculated prematurely, possibly
    missing some samples which made the result unpredictable and racy.
  * Slow devices (like mako) will after a while start to use the
    "early release" optimization that was introduced recently. However
    since we don't have dynamic queue scaling enabled to keep latency
    limited, the peak buffer latency is actually now nbuffers in some
    cases instead of nbuffers-1 frames (LP: #1491876). This extra
    latency is actually a good sign that the new feature is helping
    the slow device to maintain a better frame rate. The higher latency
    however will go away (and even reach all time lows) after we soon
    re-enable dynamic queue scaling.
  * Unresolved: The test still measures time in integer frame numbers,
    which is a feature. However this means any slight change in
    scheduling on the host where the client or server gets more time
    than the other, results in an exaggerated whole number change in
    frame latency averages. Fixes: https://bugs.launchpad.net/bugs/1447947, https://bugs.launchpad.net/bugs/1491876.

Approved by PS Jenkins bot, Alexandros Frantzis.