Most events, due to alloptions inconsistencies, cannot run in parallel. Certain events, however, may be acceptable.

Fixes #106.

For monitoring and alerting, include total of pending events in list endpoint response

A dedicated endpoint is overkill, as the list endpoint is central to the plugin operating as expected.

Fixes #100

Ensure `DOING_CRON` is set for all REST requests

If code is loaded conditionally when `DOING_CRON` is set, not setting it for all of the plugin's REST endpoints can lead to unexpected behaviour.

For example, duplicate events can be created infinitely, in combination with the skip-empty-event functionality.

Fixes #97

Clear Event Store caches when table is created

Convert to custom table

PHPUnit doesn't load the plugin until after it's called `wp_install()`, which blocks normal table creation and disables the plugin.

If table creation fails during install, or plugin is added to an installed site, create table in limited circumstances

Race conditions are a concern, so it'd be better not to create the table without some control over when it happens.

When events are capped in this way, if they don't appear in the reconstructed array, they can be continually rescheduled.

With the introduction of the block on existing-event creation introduced in 61597bc5, this approach should longer be necessary. The creation of duplicates is also greatly reduced by the table's unique key.

Fixes #94

The `WP_Query` approach is excessive

Fix tests by forcing a version of PHPUnit earlier than 6

PHPUnit 6 drops the `PHPUnit_Framework_TestCase` class, breaking all tests derived from Core. This fix is derived from Core's solution; see https://core.trac.wordpress.org/ticket/39822.

PHPUnit 6 drops the `PHPUnit_Framework_TestCase` class, breaking all tests derived from Core. This fix is derived from Core's solution; see https://core.trac.wordpress.org/ticket/39822.