Added test to prove that grouping logic is not waiting on
opRepoPostCreateDelay for new ids.This has side effect of operations
being done out of order in some cases. A real world case is login
operations can be done out of order, which also results in things like
the push subscription being on the wrong users. There is also a smaller
issue where we are simply not waiting the time limit so some 404 error
were not being avoid but would have still resulted in correct behavior
in the end.

opRepoPostCreateDelay like OperationRepo.getNextOps(), this would lead
to some being applied out of order. The only known case is when there
is a login in the queue for an Anonymous User crate and also User A and
another for User B. The anonymous User create happens first with a push
subscription which is correct. Then we have to wait for
opRepoPostCreateDelay time after that create before we can attempt to
identify it has User A, this is also ok. However we skip to User B and
try to create it and transfer the subscription, this isn't correct as
we also should wait opRepoPostCreateDelay for the new subscription id.

While this commit fixes the issue noted above there should be another
mechanism in place to prevent such an issue. This should be done in a
follow up commit.

See PR #2087 for more details.

Reversing the list means we insert each item at index 0 to keep the
order correct. Always inserting at index 0 means we no longer need to
keep an index state, which both simples the code but also means we
don't depend on state which may be wrong sometimes, noted in the
warning comment that was removed in this commit. This reversed()
logic for list used in a few places in this file already to solve this
problem.

Since opRepoPostCreateDelay is passed to delay() canAccess() should use
inclusive logic.

The OperationRepo can't juggle two different users correctly, so
stall the whole queue by opRepoPostCreateDelay. We plan to address this
limitation in a future PR.