Deleting a config checkpoint breaks the checkpoint storage

Ok, so I went back and first fixed the test to use a real state object instead of a prophesised one. It passed nicely.
Then I expanded the test coverage to get parents, and it failed.
Then I reapplied the fix to the linear histroy and the tests passed again.

So this is now ready for review.

I am not familiar enough with this API to RTBC, but the updated delete logic looks good to me. And so does the new test logic.

But since deleting a checkpoint currently results in a broken state, should we also add an update hook to fix the broken state on existing sites?

I don't think we need an update hook. There is currently no way to delete a checkpoint other than directly using the API. And since it makes all furter interactions impossible except for deleting all the checkpoints, anyone who would have encountered this bug would have solved it by just deleting all checkpoints.

Don't be shy! call the api manually, or just intall config_checkpoint_ui → and comment out the unset of the delete operation and observe that you can no longer create new checkpoints, then you fix core with this patch and see how everything works as expected.

Agree that the check for a parent does look good.

Ran the test-only job here https://git.drupalcode.org/issue/drupal-3521081/-/jobs/5169721 which gave

1) Drupal\Tests\Core\Config\Checkpoint\LinearHistoryTest::testDelete
Drupal\Core\Config\Checkpoint\UnknownCheckpointException: The checkpoint "hash2" does not exist
/builds/issue/drupal-3521081/core/lib/Drupal/Core/Config/Checkpoint/LinearHistory.php:67
/builds/issue/drupal-3521081/core/lib/Drupal/Core/Config/Checkpoint/LinearHistory.php:81
/builds/issue/drupal-3521081/core/tests/Drupal/Tests/Core/Config/Checkpoint/LinearHistoryTest.php:140
ERRORS!
Tests: 7, Assertions: 35, Errors: 1.

Which seems like a good check.

Don't see any open threads or discussions.
Issue summary appears complete

Going to mark it.