gank a thread and sleep instead of scheduling, cope with broken assumptions about queue size and timing

[niklasf]

based on #615

• somehow ... the queue got huge and now flushQ.size complexity prevents recovery -> an estimate for the size is enough, so use a separate atomic integer to get queue size in O(1)
• somehow ... time spent flushing is significant compared to configured interval size -> effectively subtract time spent flushing from interval
• somehow ... we can't keep up despite the sleep time going to zero -> too bad ... we only have this one thread (in particular, computing a more accurate maxDelayFactor based on the real interval wouldn't help, because the loop is already hot)

[ornicar]

    public static void sleep(long millis, int nanos) throws InterruptedException {
        if (nanos < 0 || nanos > 999999) {
            throw new IllegalArgumentException("nanosecond timeout value out of range");
        }

Are we sure we'll never call Thread.sleep(0, nanos) with nanos > 999999? Because I think that would blow lila-ws up.

[niklasf]

Damn, I didn't expect that. Would have definitely been possible, depending on the configuration. Fixed.