Provide stand-alone pbench server container for external integration

[portante]

Provide a stand-alone pbench server container for external integration.

A number of the previous commits in this PR were pulled out into separate PRs, most notably PR2 #3108, #3112, #3130, #3131, #3132, and #3133.

Below are the individual itemized commits we are working with to finalize stand-alone Pbench Server container image:

1. For now OIDC server is optional
2. Remove use of unused default-host

   Remove use of unused `default-host` and anything that depended on it.
   This allows us to avoid fixing up the pbench server configuration file
   for the in-a-can server container.
   
   We also make a change to always copy the HTTPD pbench server conf file
   into place, but only fix it up with the right host name for the in-a-can
   environment.
   

3. Add rsyslog for observability
4. Do not be so aggressive and run cleanup on every ERRor of a shell command
5. Remove redundant PB_POD_NAME setting
6. Bring jenkins/runlocal inline with CI pipeline
7. Use mod_logio formatting for TTFB, in, and out

   If we have the module, mod_logio, enhance the HTTPD access logs to emit
   time-to-first-byte sent in microseconds, # of bytes received (including
   request and headers), and # of bytes sent.
   

8. Replace Apache2 with Nginx

   We also move the document root for serving files to be:
   
       /srv/pbench/public_html
   
   This has a number of advantages.  It gives us one external mount point
   for the production deployment, so that the dashboard is served from the
   same volume.  It also means the `404.html` and `50x.html` pages that
   are referenced in the Nginx configuration can eventually provided by
   the dashboard.
   
   We can also take advantage of a `maintenance.json` "page", where the
   presence of that file will cause Nginx to server a 597 code, and its
   JSON payload will be pulled from that file.
   
   Finally, this allows us to provide a method for serving the old legacy
   pages for the Agent generated HTML.
   

[webbnh]

I found a few small things to attend to.

[webbnh]

I have a few concerns:

• I think it is premature to be removing support from the CI for using both internal and external container image registries.
• I'm not sure how the container will function without the Pip installs.
• I don't think that combining the various pod spec YAML files is actually producing a benefit -- I think the proliferation of parameters makes it unusable for humans without a wrapper script (which isn't included in this PR). (I think it would probably be better to just delete the previous pod.yml file, as I don't think we're going to require a pod with pre-loaded data.)

And, there are some other smaller items and questions.

[portante]

FWIW, I've pulled a few of these commits off into PR #3087 since they are independent of the direction suggested by this PR.

[webbnh]

👍

[portante]

I believe I have addressed all out-standing review comments. Thank you, everyone!

[webbnh]

👍

[webbnh]

👍