After some good discussion on IRC with @mvo and @pedronis, there are two independent things we want to do. One addresses this specific case, the other addresses similar cases in the future (right now non-existent).
The case of configure-snapd task
In the specific case of configure-snapd, the ideal scenario is that we never create the task to begin with, because there’s very little benefit in running a configure task from snapd that will configure snapd when snapd updates snapd! Does that sound repetitive? Well, exactly. 
When such an update happens, snapd is already in control, and if it needs to perform any changes it can always just do them, and in the specific places that need the change. This is much safer than the danger of doing such re-entrant logic in sensitive scenarios. This is also quite simple to do right.
Note that this change should not affect the behavior of the snap set command. This will still create the task.
All similar cases in the future
The second thing we want to do is to find a way to prevent similar problems from affecting any other task kinds in the future. That’s not a real problem today, but it may be once we add more task kinds that fall onto the critical pipeline of refreshes and reverts. So at some point in the upcoming releases, we should change snapd so that unknown tasks are aborted in short time. This requires a bit of care because right now our task handlers are completely independent from one another, which means there’s no single place with global knowledge of all task handlers. So we need to carefully design a mechanism that can decide when a task ought to be handled already, but wasn’t and most likely (or definitely) can’t be handled by the current snapd. This will fix any future cases similar to the original problem we observed here.
