V15: Show server configuration when configuring the Upload Field

[iOvergaard]

Description

Adds a notice and validation to the data type configuration of Upload Field to notify the CMS developer about the effects of the current server configuration on the Accepted file extensions on the Upload Field. For good measure, we also mention the maximum file size in the notice, even though it does not affect the extensions. This is to help the developer understand all of the limitations at once.

The server allows setting Content::AllowedUploadedFileExtensions and Content::DisallowedUploadedFileExtensions, which can have an inverse effect on the configured Accepted file extensions on the Upload Field. You may end up in a situation where you allow too much on the client that will then ultimately end up being denied on the server.

The CMS developer is first notified of potential conflicts with the server. Note, however, if the server only disallows certain types, as in the example above, you can set whatever you want in the accepted types below.

If you type one of the disallowed extensions in the field, you will now be prevented from saving:

To accomplish this, I have created a new property editor UI called "Accepted Types" that extends the multiple text string editor. This type adds its validation based on the newly created UmbTemporaryFileConfigRepository.

How to test

1. You will have to set one or more of the mentioned server settings
2. Create an Upload Field, or edit an existing
3. See if you can save an invalid configuration as well as the inverse

[leekelleher]

Tested out, all working great. 🚀

I've renamed the property-editor to be "Accepted Upload Types", as "Accepted Types" felt too general.

[nielslyngsoe]

Hi @iOvergaard and @leekelleher

Just want to mention that I spotted the changes in this PR regarding property-editor-ui-multiple-text-string.element.ts, and I have to mention that it is a bit off, in regards to how we are supposed to do Validation for Property Editors.

I know we are missing documentation, but I just wanted to make sure we handle this correctly going forward.

We should not add the umb-form-validation-message component in property editors, that is already done by the Umb-Property component.
This Validation Context is also not connected to the parent so it is not preventing any Publishing, there is not knowledge from the out side about these validation issues.

So we do not need a Valication Context unless we like to scope the validation messages for a component, and in this cases that is not needed.

So what should be done instead is to make the Property Editor UI a Form Control. and append the input as a form control of it. Once that is done the rest of what was added as part of this PR can go away.

Addition:
I spotted this as part on an investigation and a bit later I had to correct this, cause the Validation Context from here bound it self to the workspace, giving us trouble. So it is corrected now, just so you now if you get to read this message.