Remove OSDF env vars and deprecation notice

[jhiemstrawisc]

@matyasselmeci pointed out a poorly-worded warning:

Environment variables with OSDF prefix will be deprecated in the next feature release. Please use PELICAN prefix instead.

Rather than fix the warning message, which we've been printing for over a year, let's do what we promised to eons ago -- remove them!

[github-actions]

This issue is stale because it has been open for 60 days with no activity.

[jhiemstrawisc]

@williamnswanson, do you have a sense of how much headache it will cause if I move forward with this for v7.24? I've been punting to limit impact on operations, but I'm not sure whether changing these env vars is actively on someone's "todo" list.

[williamnswanson]

Our testing and rollout of v7.24 might be delayed some? IIRC, the NRP resources are all off OSDF_* style envvars, so I think only a minority of out services will need to be touched (and some of our older bases are configured to set both OSDF_* and PELICAN_* style envvars, based on setting the values of the OSDF_* style to whatever the value of the PELICAN_* style one is). This is a assuming that OSDF_* style envvars don't break things by being set (just get silently ignored) and that we aren't being rushed by other backwards-compat / upgrade-ordering problems.

I'm a bit more concerned about getting the notice out to people who aren't in the know, since lots of people don't necessarily check release notes (or check intervening notes when skipping versions during upgrades). We'll need to some up with something a bit better than remembering to tell them all individually during troubleshooting sessions.

[jhiemstrawisc]

I'm fine delaying a few more releases if we can come up with a plan that helps devs solve the issue of "we've been printing deprecation notices for over a year, but nobody reads them." My biggest concern isn't this exact issue, but the fact that it's really difficult for us to clean house when no amount of time between deprecating old stuff and turning it off will be enough for people to have migrated to the new stuff.

If I bump this back to something like 7.25/26, would the next few months be enough for the switch over on services we operate? If external sys admins choose not to read the release notes for the services they're upgrading, I think that's on them.

[jhiemstrawisc]

Moreover, I'd be interested in sitting down as a group sometime to draft a protocol that gives both Ops and the Devs a reasonable timeline for these kinds of things.