Story: As an OpenShift admin I can configure the integrated image registry to fail when its layer storage is not writeable so that I can fail-fast in configurations where this is deemed necessary, e.g. when the registry is solely used as a pull-through cache.

Why this is needed: When the image registry is used as a pull-through cache the image layers are supposed to be written to the registry's layer storage (filesystem or object storage bucket) in parallel of getting streamed to the client. The pull-thru will succeed even in the case layers couldn't be cached because the storage is not writable. This is by design currently: https://github.com/openshift/docker-distribution/blob/6b2f5d2f1f432f14c7ea0b04f9c84a81ae9ef12e/registry/handlers/app.go?plain=1#L390 because the registry still allows images to be pulled that are stored in the cache already, e.g. when writes fail only intermittently or because the storage out of capacity. In these cases, the existing content in the registry still has value, and shutting it down would cause more outages than necessary.
However, in a scenario where the integrated image registry is primarily used as a pull-through cache, this may be undesirable because every pull includes writes, and the cache will never be usable, which violates expectations. This will only surface when the upstream registry is actually unavailable and images are attempted to be pulled from cache.

Acceptance criteria:

• a property in configs.imageregistry.operator.openshift.io/cluster to disallow read-only storage, the default is False to retain backwards compatibility
• a readiness probe that implements a file-system level check that tries to write to the storage location that would normally host the layer blobs
• the readiness probe only gets added when the storage configuration of the image registry is set to pvc or emptyDir and when the above discussed spec property is switched to True