Implement a queuing system for the auto-purge routines

[raamdev]

Forked from #313 and #288.

In #313 @jaswsinc writes...

What came to my mind the other day when I working on this, was that perhaps we could work on queuing these auto-purging routines instead of processing them in real-time; i.e. letting the hooks run as they do now, but instead of acting on these events, we hold-off until right before a script's shutdown phase; once WordPress is done with the tasks that it has been asked to do.

I see a few advantages to this...

• We can run through everything that needs to occur once all of the hooks are fired, and work to optimize the amount of directory scanning that really is needed to accomplish what we need to do as we purge cache files. In short, optimizing QC even further.
• It may allow us to better formulate (and consolidate) the Dashboard notices associated with automatic cache purging. Instead of these purging routines being scattered about in the codebase, they could theoretically be consolidated; and where they all occur together, as much as possible.
• This practice, in and of itself, would defer the execution of certain routines that Quick Cache runs, until such time as WordPress it finished with the tasks it was assigned. Therefore, things like the status of a post being changed while a hook is running, would not be nearly as messy for us to deal with.
• It might allow for a load-balanced approach to come in the future, where the automatic purging routines could perhaps run in phases on very large sites. That's another issue/discussion I think. But this refactoring might set the stage for something like this occur later.

[jaswrks]

Cool! I'm thinking that we could start by creating a new class member that would take advantage of the $static property that QC already has. This could be used to store details about each queued event that we collect in other places. So we might have a new class member that looks something like this.

public function enqueue_auto_purge_event(array $event)
{
    static::$static[__FUNCTION__][] = $event;
}

That's just a rough outline, very rough. haha ~ Anyway, later we could loop back through this array (i.e. at end end of the script's execution) and iterate all of the auto-purge events that took place, and decide how to deal with the purges that need to occur — in the most optimized way.

[raamdev]

@jaswsinc Sounds good!

---

Related issues that should be worked on first

• [ ] Refactor codebase to utilize delete_files_from_host_cache_dir()
• [ ] Refactor codebase to utilize purge_files_from_host_cache_dir()
• [ ] Refactor codebase to utilize clear_files_from_host_cache_dir()