✨ Offer /metrics and /debug/pprof from controller and agent

[MikeSpreitzer]

Summary

This PR fills out the matrix of offering /metrics and /debug/pprof from the controller and agent. Previously the only thing offered was /metrics from the agent.

After #67 merges there will be more work to do about /metrics and /debug/pprof in the Helm chart.

Related issue(s)

This is part of addressing kubestellar/kubestellar#2094 and kubestellar/kubestellar#2158

[ezrasilvera]

1. Should we add an option to disable (at list the pprof data) ?
2. Why do we need the pprof at different server/port ? can't we just use a different path in the same base URL ?

[MikeSpreitzer]

@ezrasilvera:

1. We should have a discussion of security design. It will probably include options to enable/disable both ports as well as additional stuff. I think it is beyond the immediate needs.
2. When using controller-runtime, the support for those two endpoints opens two distinct sockets, so they have to be on different ports. I opted to follow the same pattern for the other controllers for the sake of consistency.

[pdettori]

/lgtm

[ezrasilvera]

@MikeSpreitzer
(1) - Sounds good
(2) _ I think the plan was always to convert the controller-runtime, not sure adopting the controller-runtime on the other controllers is reasonable. So overall how many sockets do we open now on (across all our controllers) ?

/hold

[ezrasilvera]

Added "request changes" just to make sure we resolve the second Q..

[MikeSpreitzer]

@ezrasilvera: yes, my understanding also is that we plan to switch away from controller-runtime. But that is beyond the scope of this PR.

Regarding number of sockets, remember that each Pod has its own set of sockets. I do not think we are anywhere near having a problem with the number of sockets open on a given Pod.