Downtime set by origin and cache

[h2zh]

Now origin and cache server can set their own downtime in the director by simply sending a request with payload {"enableDowntime": true/false} to API /api/v1.0/downtime. Then this PR will take care of the setting in the backend.

This is a backend change. Frontend UI is not included.

Closes #1251

[CannonLock]

Two small items and one big one that might result in some refactoring.

It is unwieldy to work with one off endpoints like this that only are there to mark a boolean. Is there any way that we can design this more RESTfully so that we are instead POSTing a body like {downtime: true/false} to /director/servers/.

This way if we ever want to adjust a servers state we can just tack it on the same POST request rather then creating a whole new endpoint.

I realize this is not easy as the ServerName in this case is a url which is a unwieldy url key. Is there anyway that we can get the ServerAd from the Servername?

There are other endpoints in Pelican that follow this model that I hope to change someday as well: https://github.com/orgs/PelicanPlatform/discussions/1688

[CannonLock]

Suggested change

	Status: server_structs.RespFailed,
	Status: server_structs.RespOK,

[CannonLock]

Why pass in Hostname if you don't use it?

[bbockelm]

I don't think this approach will work:

1. The information is sent once, meaning the director has to actually be up and functional or the downtime is lost. That conflicts with the whole idea of periodically sending the service's state to the director.

• Instead of adding the new API, make the service state part of the ad and send out a new ad. Basically, adding a new field to what we tell the director about ourselves.

2. If you restart the origin/cache, it doesn't know what state it is in. That's fundamental concept: the service is an independent entity, it can't use the director as its "memory".

• This information needs to be persisted at the service level. Make sure to talk to @CannonLock about what information should go into a downtime (it's not a boolean - e.g., there should be a start time, end time, who created the downtime, a description. We should model loosely on the downtimes we create in topology)..

Also - there's a new API and no corresponding documentation in the OpenAPI schema.

[bbockelm]

Additionally - when creating commit messages, please follow the advice starting in this paragraph:

• The subject should state what the commit does.
• The body should cover why the change is needed.
• If the change is particularly complex, then you can cover the details of what the change is/how the change works.

Not every commit message is going to be perfect but we should always strive to better.

[h2zh]

Proposed system design based on @bbockelm's comment and conversation with @CannonLock.

Rules between OSDF Federation admin and Origin/Cache admin: (checked with @williamnswanson)

1. The OSDF admin can set any server to downtime.
2. If the Origin administrator sets its own downtime, then OSDF admin cannot revoke the downtime of that origin.

Some design thoughts:

1. Need to create a db for Cache to persist the downtime there, while Cache server is stateless at the moment - thinking of implementing it in another PR in case this one goes too giant.