What type of PR is this?

/kind feature

What this PR does / why we need it:

When enabled, the internal repair feature uses the storage.CheckEverything() helper function to configure what the storage.Check() should check for when scanning the storage directory. The following options are enabled:

func CheckEverything() *CheckOptions {
	return &CheckOptions{
		LayerDigests:   true,
		LayerMountable: true,
		LayerContents:  true,
		LayerData:      true,
		ImageData:      true,
		ContainerData:  true,
	}
}

Two of these options, LayerDigests and LayerContents, are known to be I/O and CPU intensive, and both of these options are used to perform storage integrity checks and require the contents of the images to be read, checksums generated, and the current state compared against the desired state. As such, depending on the number of images, the layers each image has, and the number of files within each layer, it can take a considerable amount of time before the storage scan with both of these options enabled will complete.

Even though CRI-O only performs storage checks and repairs following an unclean shutdown, with the two checks mentioned earlier options enabled, it can take CRI-O some time to finish storage repairs. During this time, it won't be able to serve API requests. This can lead to the kubelet not being able to get responses to its requests in time, and eventually assuming that CRI-O is not responsive and proceed to make this specific node NotReady, which is undesirable.

Thus, to mitigate the problem with storage scans potentially taking a long time to complete, we are going to switch to a custom configuration for the storage.Check() that turns off these expensive checks and only turns on checks that allow CRI-O to perform a "quick" scan of the storage directory.

This quick scan should cover most of the common types of storage failures and take significantly less time to complete. However, this comes at the expense of container image integrity verification, where files that are missing from the image or files that have their content altered will no longer be detected.

The goal of the internal repair is to ensure that CRI-O can recover from issues surrounding a corrupted storage directory on start-up, with an added option only to remove corrupted images and containers when attempting a repair, compared to removing the entire storage directory content. Hence, trading scan run time for correctness is acceptable.

While at it, change the internal repair option to be enabled by default and add a new crio check sub-command, which allows to check the storage directory for errors and repair it, if needed.

Related:

• Initial implementation of consistency checks containers/storage#1569
• feat: check for clean shutdown on reboot #7190
• make use of c/storage Check() and Repair() functions #7177

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

None

Does this PR introduce a user-facing change?

Update the type of checks the internal repair feature performs on CRI-O's start-up following an unclean shutdown, enable the internal repair option by default, and add a new `crio check` sub-command.