Implement the OIDCClientSecretRequest API

This commit is a WIP commit because it doesn't include many tests
for the new feature.

Co-authored-by: Ryan Richard <richardry@vmware.com>
Co-authored-by: Benjamin A. Petersen <ben@benjaminapetersen.me>

deploy/supervisor/deployment.yaml

@@ -98,10 +98,26 @@ spec:
             readOnlyRootFilesystem: true
           resources:
             requests:
-              cpu: "100m"
+              #! If OIDCClient CRs are being used, then the Supervisor needs enough CPU to run expensive bcrypt
+              #! operations inside the implementation of the token endpoint for any authcode flows performed by those
+              #! clients, so for that use case administrators may wish to increase the requests.cpu value to more
+              #! closely align with their anticipated needs. Increasing this value will cause Kubernetes to give more
+              #! available CPU to this process during times of high CPU contention. By default, don't ask for too much
+              #! because that would make it impossible to install the Pinniped Supervisor on small clusters.
+              #! Aside from performing bcrypts at the token endpoint for those clients, the Supervisor is not a
+              #! particularly CPU-intensive process.
+              cpu: "100m" #! by default, request one-tenth of a CPU
               memory: "128Mi"
             limits:
-              cpu: "100m"
+              #! By declaring a CPU limit that is not equal to the CPU request value, the Supervisor will be classified
+              #! by Kubernetes to have "burstable" quality of service.
+              #! See https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-burstable
+              #! If OIDCClient CRs are being used, and lots of simultaneous users have active sessions, then it is hard
+              #! pre-determine what the CPU limit should be for that use case. Guessing too low would cause the
+              #! pod's CPU usage to be throttled, resulting in poor performance. Guessing too high would allow clients
+              #! to cause the usage of lots of CPU resources. Administrators who have a good sense of anticipated usage
+              #! patterns may choose to set the requests.cpu and limits.cpu differently from these defaults.
+              cpu: "1000m" #! by default, throttle each pod's usage at 1 CPU
               memory: "128Mi"
           volumeMounts:
             - name: config-volume