In the spirit of @davidwdan's PR #142, this PR allows the creation of loop events outside an execute context, however it still allows stacking of event loops and provides for consistent testing environments. The model here is inspired by @WyriHaximus's comment, allowing for both the React-style and Amp-style of creating events in the event loop.

With these changes both of the models below work as expected.

// React-style
Loop::defer(function () {
    echo '1' . PHP_EOL;
});

Loop::delay(1000, function () {
    echo '2' . PHP_EOL;
});

Loop::delay(2000, function () {
    echo '3' . PHP_EOL;
});

Loop::execute();

// Amp-style
Loop::execute(function () {
    Loop::defer(function () {
        echo '1' . PHP_EOL;
    });

    Loop::delay(1000, function () {
        echo '2' . PHP_EOL;
    });

    Loop::delay(2000, function () {
        echo '3' . PHP_EOL;
    });
});

Both will output:

1
2
3

Summary of Changes

• Loop::execute() now runs the currently active loop driver when invoked, allowing events to be created outside a running event loop.
• The callback to Loop::execute() is now optional.
• Loop::resetDriver() allows the active loop driver instance to be nulled if a loop is not running, allowing tests to easily reset the environment.
• If no active driver instance exists when Loop::execute() is invoked, the driver instance will automatically be set to null when Loop::execute() returns. If an active driver instance exists when Loop::execute() is invoked, that instance will remain as the active driver after Loop::execute() returns. This behavior preserves the state of Loop before and after Loop::execute() is invoked.
• Loop::createDriver() is now public to allow usage as the second parameter to Loop::execute().
• Stacked calls to Loop::execute() reuse the same active driver unless an a new instance is provided as the second parameter.
• Setting the loop factory with Loop::setFactory() does not reset the active driver instance.