add bulk cancel by hook/group to table store

[rrennick]

This PR adds two bulk cancel functions to the table data store with a unit test for each function

• cancel_actions_by_group( $group_slug ) cancels pending actions by group
• cancel_actions_by_hook( $hook_name ) cancels pending actions by hook

This is a prerequisite for woocommerce/woocommerce-admin#2766 to allow bulk cancelation of pending actions.

In future, other plugins using AS will also be able to take advantage of these function to cancel their pending actions on de-activation.

[rrennick]

@thenbrent The test failure was a travis download/install error. I don't have the option to restart the test.

[thenbrent]

@rrennick this is looking good. I think it needs a few additions though:

1. the cancellation log even should still be logged on these actions, even if they're "bulk cancelled", otherwise, we won't be able to trace their history.
2. ideally, these methods should be added to the base ActionScheduler_Store class too, and implemented using loops, so there is a default implementation across all data stores
3. as_unschedule_all_actions() should be updated to use these new methods when possible, thanks to the perf improvements that come from them.

[rrennick]

the cancellation log even should still be logged on these actions, even if they're "bulk cancelled", otherwise, we won't be able to trace their history.

In WC Admin, we opted to cancel the actions and allow them to be removed by the auto purge in Action Scheduler instead of deleting the actions as changing the status could be done with a single query. For the purposes of plugin deactivation I think it would be better to provide a method of deleting any related pending actions than cancelling and adding log entries.

[thenbrent]

For the purposes of plugin deactivation I think it would be better to provide a method of deleting any related pending actions than cancelling and adding log entries.

I was thinking about this issue when fixing recurring schedules.

The persistence of recurring actions after deactivating the plugin which created and required them is a strong argument for removing recurring schedules completely.

If all actions where "single", and any successive action needed to be rescheduled by the plugin using it, based on the when the prior one ran, they would automatically be cease to recur once that plugin was deactivated and wouldn't need to be cancelled.

This is mostly moot now because I went the route of fixing schedules, but I'm noting it as an alternative approach.

I still think having a log is important to help trace the reason for the cancellation (and time/date).

[rrennick]

@thenbrent Can you restart the one test that failed? It ran right about midnight UTC, so tomorrow could have been in 30 seconds and subtracting the minute put $date in the past.

If that test passes, this is ready for re-review.

[thenbrent]

This LGTM.

I added SHA: 76e149d to provide logging for bulk cancellation done via the ActionScheduler_Store fallback methods. Tests are still passing, so merging now so we can tag 3.0.0-beta-1.