UI: [VAULT-21532] Create message

[kiannaquach]

The create/edit form will be simplified once the form refresh work starts happening. Most of this create/edit form component uses HDS radiosets and datetime-local. Alternatively, I could also add this to the form-field component to simplify this code.

Things fixed from bugs I found:

• On the list view, it was using a previous iteration of the ConfirmAction. I updated it so that it uses the updated version.
• I accidentally merged the wrong merge conflict change for one of sidebar tests into the sidebranch I fix that issue here.

TODO:

• update the start and end time so that it prepopulates the datetime-local and update the POST request to accept an id on edit VAULT-21534
• selecting "never" for end time doesn't current work with the api since support hasn't been added yet.
• write acceptance tests for create / edit when backend merges the api to main.

[kiannaquach]

This PR is reliant on the new changes to the radio editType in the FormField component. #24542

[hashishaw]

Excellent work! Just one small question, but great job working through all the comments 🚢

[hellobontempo]

Instead of having this component manage setting the model value, could you just pass the attribute and an "onChange" function that passes back the end time as either an empty string or a timestamp? I don't think you'd need a component file in that case 🤔
That way this component acts more as a fancy input, and all of the model updates happen in the create-and-edit- form

[kiannaquach]

I did something similar at one point in this PR, but removed it since I thought it was easier to understand this way since you're able to see the logic in the template rather than navigating back to the create-and-edit- to see the onChange action. 🤷‍♀️ I think we'll need a component no matter what since the groupValue and formDateTime tracked properties are initially set in the constructor based on whether an endTime exists. An argument can be made that this could be in the create-and-edit- too, but I feel like this should be role of the message-expiration-date-form

[kiannaquach]

I'll make note of this as a possible improvement, but don't think it should be a blocker for merging this in the sidebranch. The next ticket I'll work on is the edit so I'll try addressing this there.

[hellobontempo]

Definitely. My suggestion was based on handling the input similar to the pattern of how other form fields work. You definitely have more context here! I find attribute changes are easier to follow if all input components are responsible for is returning the selected/inputed value. In this case, that'd be an ISO timestamp string.