Resolves issues related to the setting of a schedule for content publishing

[AndyButland]

Prerequisites

• I have added steps to test this contribution in the description below

Addresses issues raised in #17031, tracked under AB 45476 (internal HQ tracker)

Also fixes #17830 tracked under AB 47430

Also fixes #18297 tracked under AB 48986

Description

Reported issue:

#17031 describes several issues related to the setting and reading of scheduled publishing details:

1. It's not possible to see if a page is scheduled in the "info" section of the page.
2. You cannot schedule an item that has not been saved yet.
3. If you try to publish an item that has been scheduled you will get an error:
4. If you click on "schedule" on an already scheduled page the dates for the previous schedule are not displayed.
5. There is no conversion between local and server time on save and display of the scheduled dates.
6. A previously set scheduled date can't be cleared.

Resolution:

With the PR merged, these issues will be addressed as follows:

1. In Umbraco 13 the details of the schedule were displayed in the "Info" tab when editing content. I've added that back now:

2. Conditions have been added now so that all the actions available as workspace action button extensions - unpublish, publish with descendants and schedule - no longer appear until the content has been saved for the first time. They all error if called on a new content item that hasn't yet been saved.
3. Getting an error presented when trying to publish and item that has been scheduled is correct behaviour, or at least aligns with what we have on 13, so I've made no changes to this.
4. Previously selected schedule is now displayed when returning to the dialog to view or change the schedule.

5. A conversion is now made between the local and server time when saving and presenting the schedule. There's no conversion when running locally as of course the server and local time are the same, but this update should resolve issues where the times aren't the same, and aligns with the behaviour we had on 13.
6. A previously set schedule can now be cleared.

To Test:

• Use the schedule dialog for a new and existing content item to verify issues 1, 2, 4 and 6 are resolved.
• Go to DevTools in your browser and enable the Sensors menu, set your timezone to something else than the server and schedule a document. Verify that the saved schedule is saved to the database with the same value as we have in an Umbraco 13 site (in umbracoContentSchedule), which will indicate that issue 5 is resolved.
• Change your timezone to something else and verify that the time displayed for scheduling is relative.

Caveats

1. There is no validation on the times set as of yet (i.e. you can set an unpublish time before the publish time, etc). The server will fail the scheduling, but we can prevent it in the client before submitting. We will do this in another PR.
2. The document is not saved before scheduling, which was the behavior in V13. That also means that no validation is being run on the fields allowing you to circumvent the validation system. We will also handle this in another PR.

[AndyButland]

I've combined this with the work @Migaroez did in #17535, as we'd overlapped slightly. Have picked out his updates and ensured they worked with mine in the UI.

It's working a lot better now in terms of saving a schedule and having it displayed in the UI again so you can view and edit it.

The only issue I can still see is for variant content, in that when you view or set the schedule, you don't see the previous schedule of the non-active variant.

E.g. here I'm looking at English and have clicked the Schedule button:

Which correctly shows the previously set English schedule and has the Italian one hidden. But if I click to view or set the Italian one, I don't see the previously set schedule:

It's OK though if I've made a change to the Italian content.

I can kind of see why... but it seems that this dialog has really been built around displaying data for the active or changed variants. Here that doesn't seem right - seems we should be able to see and set a schedule for a non-active and non-changed variant,

[iOvergaard]

I have handled @AndyButland's issue by sending all the options as values to the modal and adding a new data option called activeVariants to ensure that only the changed variants are expanded by default.

[leekelleher]

Tested it out, it's all looking good. Great work here!

The only thing I picked up on was that when the Schedule action is triggered, the notification toast says "Document published".

We'll need to review how the notification from the publish() method in document-publishing.repository.ts is handled.

If we want to handle that in a separate PR, then I'm happy to approve on this PR.

[leekelleher]

Tested latest fixes, all looking good. 🚀

[nul800sebastiaan]

Just a heads up @AndyButland: screen readers read capitalization differently, so it will be more like: "Remove. At." than "Remove at".

[AndyButland]

Thanks. I didn't know that but makes sense now you point it out.

Trying to recall why I changed this - I think it was aligning with other labels where this is displayed, but can't see it now. Will review and revert,