GDB Checkpoint Issue

There's currently an issue with GDB checkpoints making them behave in (probably) unintended ways.

Here's a quick run down of the behavior:

• user sets checkpoint at time T (with the checkpoint command)
• the checkpoint is not explicit, so it will rely on an internal checkpoint at some time (T-n)
• replay continues until next stop

During the continue until next stop, the internal checkpoint at (T-n) might have been cleaned up & removed by the supervisor. If there's an internal checkpoint before it, the GDB checkpoint will restart from that instead (and if there is none before T-n, essentially restarting that checkpoint amounts to restarting the replay from the beginning).

This is probably not the intended behavior.

This issue will be fixed by the Persistent Checkpoint PR, because that PR requires this "searching backwards for internal checkpoints"-functionality (and has also refactored out the checkpoint refcount management, which is what keeps "internal checkpoints" alive).

So this issue will be closed by #3406 once it's done.

I came across this bug when finishing up that PR. So once I can get an "ok" that we can solve it by pulling in that PR when it's done, I'll move forward with updating the PR (rebasing onto master) - otherwise I'll have to fix this issue first (which is fine too).

Review the checkpoint behavior described here alongside PR #3406, which the issue identifies as the intended resolution. Done means a user-created GDB checkpoint no longer falls back to an older internal checkpoint when its supporting checkpoint has been removed.