Adjust implementation of DeleteClient

[ionut-arm]

During our weekly call we decided DeleteClient should be interpreted as "make a best effort to remove all resources belonging to client X or to unlink those resources if the backend fails to remove them". This is in contrast with our previous expectation which saw DeleteClient as a sum of Destroy<Resource>, e.g. PsaDestroyKey, operations and which currently fails at the first "sub-operation" failure.

The new semantics should be that all providers must do a best-effort job of removing all references and metadata to resources belonging to client X, even when removing the resource returns an error code from the backend. The only case where an error response code should be returned to the Parsec client is when a failure occurs during metadata cleanup, and thus a new service client with the same identity would potentially be able to access some old resources (or have conflicts when creating new ones with identical names).

The contract and interface will remain the same (although we will probably need a new response code specific for these errors), but the implementation will change. We also need to make sure the documentation for this operation is consistent with these semantics and sufficiently clear.

[ionut-arm]

All errors encountered during the deletion process should be logged, as this will be the only way to tell what happened.

[hug-dev]

I believe part of this is also connected to #319: we need to make sure that PsaDestroyKey would at least destroy the key mappings if the key exist (that should never really fail). That way we can be ensured that even if the operation failed, a key with the same name can be created again on any provider.
We need to review the PSA status error codes and check if some of them returned by psa_destroy_key specify if the key can be used again or not.

About DeleteClient, if multiple psa_destroy_key fail for different reasons (different response status codes), which one would we return?

[ionut-arm]

We need to review the PSA status error codes and check if some of them returned by psa_destroy_key specify if the key can be used again or not.

Indeed, my worry is that in some cases, for some providers, we won't be able to guarantee that the key is destroyed and unusable - we are helped by the fact that the identifier used by clients is not related in any way to the identifier used by the backend. But maybe we need to solve #319 first and then figure out how this one fits in

[hug-dev]

From #319

For DeleteClient, we can go through all keys on all providers and delete them all without checking the Result but logging if an error happens. Either we set that operation to never fail, or we return a PsaGenericError, or one of the errors encountered?

I think this should go in the issue for DeleteClient, but yeah - probably return PsaGenericError or something like that, don't think it makes sense to return one of the errors encountered (I mean, which one would you return if more than one happened...)

I have just been thinking, Rust being Rust, we can not return both an error (ie PsaGenericError) and the list of clients on providers that did not fail. So I am thinking we might just declare this operation as one that can not fail? If it fails on any of the providers, we would return an empty list for this one.

Similarly I am looking at our other core operations that are looping through providers: list_keys and list_clients. Should we have the same "best-effort" approach for those?

1. The operation can never fail
2. If it fails on one provider, it will return an empty list for that provider