Refactor updating user role to save local user asynchronously

[crazytonyli]

Similar to #20239, but this PR only changes the synchronous performAndSave to asynchronous one just in one place, since the diff is a bit messy. See pbArwn-5Qy-p2#how-does-this-apply-to-the-wp-and-jp-ios-apps for detailed reasoning.

Test instructions

Go to My Sites -> People, invite new user and edit their role. Make sure the role is updated correctly.

Regression Notes

1. Potential unintended areas of impact
   None. As the refactored function is only used in the "People" screen.

2. What I did to test those areas of impact (or what existing automated tests I relied on)
   What described in the "Test instructions"

3. What automated tests I added (or what prevented me from doing so)
   None.

PR submission checklist:

• I have completed the Regression Notes.
• I have considered adding unit tests for my changes.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[wpmobilebot]

You can test the changes in WordPress from this Pull Request by:

• Clicking here or scanning the QR code below to access App Center
• Then installing the build number pr20244-61e81f2 on your iPhone

If you need access to App Center, please ask a maintainer to add you.

[wpmobilebot]

You can test the changes in Jetpack from this Pull Request by:

• Clicking here or scanning the QR code below to access App Center
• Then installing the build number pr20244-61e81f2 on your iPhone

If you need access to App Center, please ask a maintainer to add you.

[mokagio]

What do you think of making this a nested type?

extension PeopleService {

  enum Error: Swift.Error {

Probably not worth it because then every existing Error usage in this file should be updated to Swift.Error to avoid clashing.

[crazytonyli]

Yeah, that's why I didn't put the new Error type under PeopleService.

[mokagio]

Just to confirm I'm reading the diff correctly, this is a new behavior from the previous code and runs with error equal .userNotFoundLocally if managedPersonFromPerson(_:, in:) doesn't find a match.

In the previous version, instead, the app would have called crashed when failure?(error, reloadedPerson) because no value would have been assigned to var reloadedPerson: User! due to the early return.

Is that correct?

[crazytonyli]

The app wouldn't crash, but neither the success nor the failure block would be called. With this new behaviour, as you noted, the failures will be called if couldn't find the ManagedPerson.

However, I don't think this error would actually happen though, since this function is called immediately after the user changes the ManagerPerson instance's role on UI, it's not likely that the ManagedPerson is deleted in that split second.