Avoid watcher ID collisions after PHP_INT_MAX tickover

[DaveRandom]

Since repeat() alarms keep the same ID across multiple schedulings, a repeat() scheduled early in an execution will have a low ID. When the id counter ticks over PHP_INT_MAX, it's possible that the original alarm may disappear into the ether.

[DaveRandom]

Never mind, this is wrong. I may have a worthwhile PR but it needs some more work

[rdlowrey]

Right. I've given this problem some thought and haven't come up with a satisfactory solution either. The integers are the fastest lookup mechanism (and the increment operation the fastest way to generate unique IDs), but these are obviously prone to the issue you raise. Perhaps we could rollover to PHP_INT_MAX * -1 which would effectively double the capacity and then start using an isset check once it arrives back at zero? The performance aspect is the first concern since this library is the basis for all my server work.

[DaveRandom]

@rdlowrey take a look at DaveRandom@62e9a79

I haven't been able to test it properly as I don't have an environment readily available, but I think that approach should solve the problem highlighted in this PR (just needs a couple more isset()s) and hopefully also provide some efficiency gains with the NativeReactor alarm system in general - the current impl uses asort() at the head of every alarm cycle which is quicksort so it's O(wtf), also it uses foreach and the array gets modified during the loop which is CoW.

That branch uses a stack instead, which makes the schedule operation a little more expensive but I hope that will be outweighed by the efficiency gains in avoiding the sort/CoW.

Have a play around with it and let me know how you get on.