array_multisort changes in PR 162 break existing code

[phil-davis]

Ref: #162

The array_multisort functionality meant that for events that have equal priority and were arrays, they were sorted into "order" of those arrays.

But now they do not get sorted.

This seems to be the cause of a problem in CI of owncloud/core#41676

There are some sets of events of equal priority like:

Array
(
    [0] => 100
    [1] => 100
)
Listeners count:2
Not a Closure: array
Listener Key:0 with value of type: object
Listener Key:1 with value of type: string
Listener Value:httpPropFind
Not a Closure: array
Listener Key:0 with value of type: object
Listener Key:1 with value of type: string
Listener Value:checkPropFind

Previously those got sorted around the opposite way: checkPropFind and then httpPropFind.

I haven't dug into all of the "now not sorted" lists of events to see which one(s) actually break things. But the change certainly makes some PROPFIND requests fail.

@come-nc @provokateurin is there some way that we can make this more backward-compatible so that it still sorts a set of arrays like it did previously?

[phil-davis]

Maybe this is "a good thing", and users need to find places where they accidentally relied on listeners to the same event, with the same priority, being sorted (e.g. alphabetically for "regular" listeners).

I found one instance of this in owncloud/core#41676 and adjusted the priority of checkPropFind to 99 so that it always triggers before httpPropFind. That used to be the "accidental" behavior because checkPropFind was sorted alphabetically before httpPropFind.

But consumers do need to be aware of this and have a robust-enough test suite of their own that will find occasions where the "accidental" sorting was helping get the events to be triggered in the needed order.