use startupProbe instead of readinessProbe for rake-task based containers

[tcdowney]

• these jobs briefly listen on a socket while starting up, but do not maintain that socket long-term
  • this is done here
  • alternatively I could update them to run a long-lived TCP server in a background thread, but since the processes aren't actually webserves that feels like just a more complicated process liveness check
  • if the rake tasks crash Kubernetes will detect this on its own and restart the container. See: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-liveness-probe
• these jobs run rake tasks that will crash when something goes wrong, so the regular liveness/readiness behavior of Kubernetes should suffice
• this was "working" previously because the readiness check probe was connecting to the Istio sidecar instead of the rake task, we noticed issues once switching to a non-mesh ingress solution (like Contour)
• removed the readinessProbe entirely from the registry-buddy since it does not accept external connections by design

Addresses #91
Tracker Story: #175388005

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.

The labels on this github issue will be updated when the story is started.

[tcdowney]

Closing this for now. I'm not sure the startupProbes are working correctly on my k8s 1.18 env. They seem to be falsely succeeding...
kubernetes/kubernetes#92196