Create a migration pathway from direct-auth clients to a different auth type

[paulhowardarm]

Summary

It should be possible for a Parsec client, which was originally using direct authentication on a service endpoint, to be upgraded to a different authentication mechanism on the same endpoint without losing visibility of the assets that it created beforehand.

Use Case

Consider a single-tenant Parsec system where a single client process is using the service with direct authentication (where the client is self-declaring its own application ID, and the communication with Parsec is secured using domain socket permissions only). The system is then upgraded such that multiple clients are now able to call the service, and they are authenticated and separated using an identity system such as UID. The pre-existing client process will necessarily have to switch from using direct authentication to using UID-based authentication (this change would occur automatically via logic in the client library). However, this would inevitably change the ID of the pre-existing client from whatever hard-coded ID it was using before, into its new UID. From Parsec's perspective, this becomes a new, distinct client with a new partition in the key store. Keys that the client created before the upgrade would no longer be visible. A migration path would solve this problem, and allow the pre-existing client process to seamlessly continue working.

Details

Requires design, but possibly could be based on mappings declared in a config file, assuming some human intelligence about what the previous hard-coded value was. Or it could be something more dynamic like a RenameClient API call.

We need to consider whether we should allow this migration path to work for any new auth type, or would it be reasonable to restrict it to just UID-based systems?

[ionut-arm]

This sounds somewhat fiddly and in need of a solid design. RenameClient might work well with our new admin concept!

[hug-dev]

If with #394 we are going to support having multiple authenticators in parallel, each key from each provider from each app name will be namespaced under its own authenticator.
It could make sense to have a more fine-grained operation to move (or even copy?) one key from one authenticator to another.