feat: improve onboarding_cli resilience

[srieteja]

- What I did

• removed qr_code related components from code
• rename OnboardingUtil -> RegistrarApiUtil and consume this change
• Delete .atKeys file if onboarding process encounters an unrecoverable exception/error
• Retry each of the onboarding steps in case they encounter an exception

- How I did it

• Introduced _deleteAtKeys() which checks if the atsign is already onboarded, if not deletes the atKeys file that has been created
• Introduced OnboardingTask which is an abstract class that contains strucutre to retry a specific task in case it has encountered an Exception/Error or has not fetched necessary data. All the onboarding tasks have been rewritten by extending this class with varying maxRetries count to improve resilience.

- How to verify it

• activate_cli should be working as usual
• In case a certain task (updating pkamPubKey, encPubKey to remote) fails, onboarding_cli should retry those specific tasks. In case maxRetry count is exceeded, the .atKeys file should be deleted.
• Unit tests on the way

- Description for the changelog

• removed qr_code related components from code
• rename OnboardingUtil -> RegistrarApiUtil and consume this change
• Delete .atKeys file if onboarding process encounters an unrecoverable exception/error
• Retry each of the onboarding steps in case they encounter an exception

[srieteja]

Unit tests on the way

[gkc]

@srieteja What's the status of this PR?

[srieteja]

@gkc this PR is from before at_auth was introduced, so it requires some capacity to bring this PR up to speed. And since its not linked to a ticket anymore, it's low priority for me. Will bring this up to speed and get it closed as soon as I find some time.

[gkc]

@gkc this PR is from before at_auth was introduced, so it requires some capacity to bring this PR up to speed. And since its not linked to a ticket anymore, it's low priority for me. Will bring this up to speed and get it closed as soon as I find some time.

Makes sense, thanks @srieteja

[gkc]

@srieteja @sitaram-kalluri This PR is now very old. Should it be abandoned?

[srieteja]

I think so @gkc. It is pre at-auth so It would take too much effort to make it relevant again. But if you think this kind of modularity is needed in onboarding_cli/at_auth, I can implement this style with the current code.

I will close this an PR now.

[gkc]

Thanks @srieteja

@sitaram-kalluri - since you are currently working on another aspect of CLI resilience (not proceeding if it doesn't have permission to create the atKeys file) can you also add resilience in other places? We need to ensure

1. atKeys file is created once all of the keys have been cut
2. But the atKeys file is deleted on exit if the public keys have not been successfully saved to the atServer
3. We are left with a conundrum regarding the CRAM key. The final step should be to delete the CRAM key from the atServer; but what to do if that fails after several retries? The most sensible thing I can think to do is to implement logic in the CramVerbHandler in atServer such that if the public encryption key and at least one PKAM public key are present, then the CramVerbHandler should reject the attempt.

Please also ensure that the retries are done with exponential backoff. I'd suggest up to 5 retries with 5, 8, 13, 21, 34-seconds delays between attempts (resetting state whenever a request succeeds)

[sitaram-kalluri]

Thanks @srieteja

@sitaram-kalluri - since you are currently working on another aspect of CLI resilience (not proceeding if it doesn't have permission to create the atKeys file) can you also add resilience in other places? We need to ensure

1. atKeys file is created once all of the keys have been cut

2. But the atKeys file is deleted on exit if the public keys have not been successfully saved to the atServer

3. We are left with a conundrum regarding the CRAM key. The final step should be to delete the CRAM key from the atServer; but what to do if that fails after several retries? The most sensible thing I can think to do is to implement logic in the CramVerbHandler in atServer such that if the public encryption key and at least one PKAM public key are present, then the CramVerbHandler should reject the attempt.

Please also ensure that the retries are done with exponential backoff. I'd suggest up to 5 retries with 5, 8, 13, 21, 34-seconds delays between attempts (resetting state whenever a request succeeds)

Sure, @gkc . Will create git tickets for each item and work on them