Stop overriding hub.readinessProbe to false

[consideRatio]

The hub should never enter a "unready" state after it has become ready, but its helpful if it doesn't end up ready before its actually ready as well.

In the past, we've disabled hub.readinessProbe because:

1. It could lead to cluttering of logs, but it doesn't any more with a modern jupyterhub version
2. It could fail and making the hub unavailable - even though there wasn't another hub pod replica to delegate traffic to instead etc. It won't do this anymore though - the livenessProbe would fail first if that was the case.

If a hub readinessProbe exists, it can help with wait conditions. For example if helm upgrades with --wait, it will ensure the container doesn't crash before it becomes ready - but without a readinessProbe its considered ready directly, so helm may think its fine even though it entered a crashloop.

[github-actions]

Merging this PR will trigger the following deployment actions.

Support and Staging deployments

Cloud Provider	Cluster Name	Upgrade Support?	Reason for Support Redeploy	Upgrade Staging?	Reason for Staging Redeploy
aws	openscapes	No		Yes	Following helm chart values files were modified: common.values.yaml
kubeconfig	utoronto	No		Yes	Following helm chart values files were modified: common.values.yaml

Production deployments

Cloud Provider	Cluster Name	Hub Name	Reason for Redeploy
aws	openscapes	prod	Following helm chart values files were modified: common.values.yaml
kubeconfig	utoronto	prod	Following helm chart values files were modified: common.values.yaml
kubeconfig	utoronto	r-prod	Following helm chart values files were modified: common.values.yaml

[github-actions]

🎉🎉🎉🎉

Monitor the deployment of the hubs here 👉 https://github.com/2i2c-org/infrastructure/actions/runs/6557260917