Background Riker Frontier for Frontier Dumping

**Issue**

The hs frontier might dynamically change halfway through command execution. This means that `node X` might not be in the frontier while first speculating, but then due to the previous nodes (`node X-2`, `node X-1`, etc.) being ready to commit while `node X` is still executing, the frontier will dynamically change halfway through `node X`'s execution.

There is a chance that `node X` might be correctly speculated, so we can get a benefit from speculating before reaching the frontier. However, there is also a chance that `node X` could not have been speculated, so when it finishes executing, we have to restart it with the most recent environment (the frontier environment or the one received by the wait), losing a lot of time, especially if `node X` takes significant time to finish.

**Proposed solution**

We know that

1. when a node starts executing while in the frontier, and
2. when this node has also received a wait (most recent possible env),

will always run successfully (not need for a restart)

Instead of waiting for `node X` to finish executing, we can instead when the two conditions above are fulfilled, start executing a frontier instance of `node X` on the background (in frontier mode) that we know that once it is done executing, it will get committed. If the previous instance of `node X` (that started before the frontier moved to `node X`) fails, we can just replace the old `node X` with the new already-executing frontier instance of `node X`. If the previous instance gets correctly speculated, we just kill the background instance.

**Pros:**

* Improves worst-case performance
* Easy to implement

**Cons:**
* Background task will occupy an extra thread

For this reason this should maybe be a spec option.