fix(auth): Fix issue with extracting username during USER_PASSWORD_AUTH

[mattcreaser]

• PR title and description conform to Pull Request guidelines.

Issue #, if available: #3145

Description of changes:
This PR changes how we read the actual username back from the InitiateAuthResponse and RespondToAuthChallengeResponse.

Amplify stores various pieces of data under keys derived from the user's username, including device metadata used for device tracking. We need to be able to retrieve that metadata or later requests can fail, as in the linked issue.

The "username" supplied when signing in, however, may not be the user's actual username, because Cognito can be configured to allow customers to sign in via other attributes such as email and phone number. In these cases the identifier used to sign in does not have the same value as the username.

Amplify does not store the identifier used to sign in, instead for signed-in users it reads the username back from the stored JWT credentials, which can be different from the alias used to sign in initially. Therefore we need to be careful and ensure that any information we are storing is done under the actual username, and not just the identifier used during sign in.

The previous implementation only ever checked the challengeParams to see if they specified a username. That generally works for SRP, UserAuth, and CustomAuth because the first thing that happens is that you get back a challenge containing challengeParams. For PasswordAuth however you only get back a challenge in some situations (e.g. have enabled MFA). Otherwise you directly get back an AuthenticationResult on the initial InitiateAuth and there are no challengeParams.

This PR changes the handling so that we can get the username from either the AuthenticationResult or challengeParams, which resolves the issue.

NB: Cognito discourages storing information under the username (see warning here), so this whole setup is not ideal. We should look into migrating to use the sub as the key instead.

How did you test these changes?
(Please add a line here how the changes were tested)

Documentation update required?

• No
• Yes (Please include a PR link for the documentation update)

General Checklist

• Added Unit Tests
• Added Integration Tests
• Security oriented best practices and standards are followed (e.g. using input sanitization, principle of least privilege, etc)
• Ensure commit message has the appropriate scope (e.g fix(storage): message, feat(auth): message, chore(all): message)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[mattcreaser]

Note: this PR doesn't resolve a similar issue for the USER_AUTH flow. I've opened #3151 to cover that.

[codecov]

Codecov Report

❌ Patch coverage is 92.30769% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 54.72%. Comparing base (e7db5a7) to head (6f85432).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3149      +/-   ##
==========================================
+ Coverage   54.70%   54.72%   +0.02%     
==========================================
  Files        1046     1046              
  Lines       31251    31238      -13     
  Branches     4690     4671      -19     
==========================================
  Hits        17096    17096              
- Misses      12330    12336       +6     
+ Partials     1825     1806      -19     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.