Schema Registry is continue working even if KafkaStoreReaderThread has been stopped unexpectedly

Hello,

I would raise a question about decision behind keeping Schema Registry healthy when KafkaStoreReaderThread died.

We have a case when Kafka Access Control List(ACLs) was applied and KafkaStoreReaderThread has been stopped due to exception [KafkaStoreReader thread has died for an unknown reason](https://github.com/confluentinc/schema-registry/blob/master/core/src/main/java/io/confluent/kafka/schemaregistry/storage/KafkaStoreReaderThread.java#L301)

After that Schema Registry may work only in readonly mode with limited state which has been read before the thread crash.

As I understand, only Schema Registry restart may launch the KafkaStoreReaderThread again. If it's true then how to know that the KafkaStoreReaderThread has been stopped to restart the service(k8s pod) again?

We have an health check for _/subjects_ endpoint, I also tried [/metadata](https://github.com/confluentinc/schema-registry/issues/1267#issuecomment-820389123) endpoint and [k8s tcp health check](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-tcp-liveness-probe) on Schema Registry port.
_But Schema Registry still returns OK response:)_

To summarize:
Do we really need keep Schema Registry working if KafkaStoreReaderThread died? Or kill the Schema Registry itself to let system know about the failure?

As a suggestion, maybe it's better to kill Schema Registry by throwing FatalExitError [here](https://github.com/confluentinc/schema-registry/blob/master/core/src/main/java/io/confluent/kafka/schemaregistry/storage/KafkaStoreReaderThread.java#L301)?

What do you think?

Thank you!

Start with core/src/main/java/io/confluent/kafka/schemaregistry/storage/KafkaStoreReaderThread.java at the failure handling around line 301, then review how /subjects, /metadata, and the Kubernetes TCP health check report service health. Done means an agreed behavior for a stopped reader thread and a health signal or shutdown path that exposes the failure to Kubernetes.

Written by the indexing model from the issue text.