Alerting: Update provisioning to validate user-defined UID on create

[yuri-tceretian]

What is this feature?
Fixes provisioning service to validate user-assigned UID of alert rule and contact points, and return error if the UID does not meet the requirements.

Validation does not affect the update operation and therefore, existing resources will not be affected.

Why do we need this feature?
To enforce uniform rules for UIDs across all APIs and databases. In SQLite mode, the long UID will be accepted because the field has TEXT type. However, in MySQL and Postgres - the UID will be rejected by the database.

Also, it will help prevent users from getting in trouble while using manually assigned UIDs. For example, UID like my=abc will be accepted by provisioning but user will not be able to reach out the rule via UI.

Who is this feature for?

[Add information on what kind of user the feature is for.]

Which issue(s) does this PR fix?:

Fixes #62904

Special notes for your reviewer:

Please check that:

• It works as expected from a user's perspective.
• If this is a pre-GA feature, it is behind a feature toggle.
• The docs are updated, and if this is a notable improvement, it's added to our What's New doc.

[rwwiv]

Couple very minor nits around testing, but LGTM 🚀

[alexweav]

LGTM, nice approach with making it so only newly created objects uptake this, so it's not breaking.

What's here is good, though I suspect we could go further - check the PUT for contact points:

What happens if you PUT /contact-points/
with:

{
    ...
    "uid": "some-long-invalid-uid"
}

I honestly don't remember the behavior here - does it try to update the actual UID of the contact point? If so, we could potentially also attempt to validate in this case too (as long as we don't break updates if the path UID is already invalid to begin with).

[yuri-tceretian]

What happens if you PUT /contact-points/

I just tested it and uid in the payload is ignored. Perhaps we need to fail the request if uid is specified.