Use `Server.Hostname` as the prefix for origin/cache namespace registration

[haoming29]

As @williamnswanson reported, the ITB cache failed to start with 7.8.0 director with the following message:

 Error: error during director registration: Authorization token verification failed failed to check namespace approval status: Registry returns error when checkNamespaceStatus 400 with body {"status":"error","msg":"The namespace /caches/2607:f388:2200:99:b984:4e7d:7cf7:1568 does not exist in the registry"}

The ITB cache has Xrootd.Sitename set to CHTC-ITB-OSDF-PELICAN-CACHE but the director was using the server IP to look up the prefix of the cache at the registry, causing a 400 error.

[bbockelm]

Reopening this one.

I think the site name is more for the human / presentation layer. It's still pretty ill-defined and we don't have semantics (or even a list of valid characters!) laid out.

I think it's better to have the cache service (and eventually, the origin service) to register under its hostname, /caches/{hostname}, instead of the sitename, even if we display the human-friendly site name in the UI.

[haoming29]

Reopening this one.

I think the site name is more for the human / presentation layer. It's still pretty ill-defined and we don't have semantics (or even a list of valid characters!) laid out.

I think it's better to have the cache service (and eventually, the origin service) to register under its hostname, /caches/{hostname}, instead of the sitename, even if we display the human-friendly site name in the UI.

Think through this, I saw a chance of breaking backward compatibility. If we use /caches/{hostname} to register cache instead of /caches/{xrootd.sitename}, for caches having xrootd.sitename set, they will re-register under a different prefix and the admins need to approve them and potentially remove the old registration. With such consequences, I'd suggest doing this in 7.9 as a breaking change instead of do a patch release, and to stop the bleeding for now, the merged PR should work.