Fix OIDC access to verify TLS connection

[webbnh]

In the course of recovering from our latest challenges with the Staging server, we noticed warnings triggered by the Pbench Server accesses to the OIDC server indicating that TLS verification was disabled...which, in fact, it was...which is undesirable. It turns out that there are two places in the Pbench Server code where it connects to the OIDC server -- once during startup to make sure that the service is available and once somewhat later to fetch the public key for token decryption -- and the first was performing TLS verification but the second wasn't.

This PR provides a common mechanism for both sets of accesses to use to determine whether and how to use TLS verification. Both relevant places in the code now pull the path to the CA from the Pbench Server configuration; if the path is not provided, they use True to trigger default TLS verification using the system's trusted CA store.

This change also renames the configuration option and wordsmiths some of the relevant code comments.

[dbutenhof]

Hmm. OK, fine. I don't see much benefit in the config option name change, and technically requests supports a directory of CA files (though we're unlikely to use it) making "location" perhaps slightly more accurate than "file". (Although "ca" is a bit more specific than "cert"...)

[dbutenhof]

• black --check .
  would reformat lib/pbench/server/auth/init.py

[webbnh]

• black --check .
  would reformat lib/pbench/server/auth/init.py

Thanks for the heads-up. Apparently I removed the trailing comma when I changed the line, which gave Black the latitude to rewrap it.... 🙄

[webbnh]

Alright! This branch has been rebased on main and is ready for final review. (Apparently there are in fact no changes since the last round of reviews, because GitHub is still showing approvals...yay!) So, if the tests pass I guess I can merge with no further action, but I figured I would mention it anyway.

I don't see much benefit in the config option name change, and technically requests supports a directory of CA files (though we're unlikely to use it) making "location" perhaps slightly more accurate than "file". (Although "ca" is a bit more specific than "cert"...)

Yeah, I apologize for the churn. However, I didn't feel like the name was serving us well and I felt impelled to update the comments, so I figured I would try another name while I was at it. (Yes, the option is a bit of a swiss army knife, but I wanted "CA" in there, and so I followed our local usage which is "file".)