fix: do not allow dots in destination names

[dnephin]

A dot in a destination name makes all grants for that destination ambiguous. They could refer to multiple destinations.

For example a grant with resource=kubernetes.dev could mean the default namespace for a destination named kubernetes.dev, or it could mean the dev namespace for a destination named kubernetes.

We could decide to separate destination from the resource on the grant, which would allow us to support dots in destination names. That's a much larger change, so until we decide we need that, we have to exclude dots from destination names.

We don't have any telemetry for destination names. I think we need to make this change regardless, but we should be careful to call this out in the release notes as a potentially breaking change. We may want to combine this with the change to the connector helm chart, and the change to add a unique constraint to destination names.

[BruceMacD]

Can we add a migration to this change to check the database for destinations with dots in their names and smoothly update them?

[dnephin]

Can we add a migration to this change to check the database for destinations with dots in their names and smoothly update them?

Unfortunately I don't think that migration will make it a smooth update. It will fix the destination name, but if a connector is running for that destination the connector will attempt to update to use the old destination name and start failing. It also doesn't address the grants, which all need to be updated for the new name.

The upgrade path for a user with dots in their destination name would be:

1. restart the connector with the new destination name
2. recreate all grants with the correct destination name
3. remove the old destination

The migration for the destination name will remove the last step at least, so I'll add it to this PR.

[dnephin]

Added a migration to replace dots with underscores

[dnephin]

I realize now I probably could have done this in a single update statement with the postgres replace function (https://www.postgresql.org/docs/current/functions-string.html), but I think this is fine. I'll try to remember that option for next time.