[local_auth_darwin] - Converts implementation to Swift

[Mairramer]

Part of flutter/flutter#119015
Closes flutter/flutter#119104

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or this PR is exempt from CHANGELOG changes.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[stuartmorgan]

As a high-level comment on my specific comments above: as discussed earlier, the goal of a Swift conversion PR should be to convert the existing logic to Swift as directly as possible, modulo any language-specific idiomatic differences. A conversion is already a relatively high-risk change due to the magnitude of code being changed; intentionally mixing in refactors, subjective changes to implementation approach, etc. is highly undesirable in such a PR because it increases the risk even futher.

Any delta between the Obj-C logic and the Swift logic in this PR should be clearly and directly attributable to a language-specific reason.

If you have subjective disagreements about how the code is currently structured, please feel free to either make prequel PRs or follow-up PRs that make those changes, so they can be discussed, reviewed, and tested in isolation, rather than as part of a complete rewrite of the code.

[Mairramer]

As a high-level comment on my specific comments above: as discussed earlier, the goal of a Swift conversion PR should be to convert the existing logic to Swift as directly as possible, modulo any language-specific idiomatic differences. A conversion is already a relatively high-risk change due to the magnitude of code being changed; intentionally mixing in refactors, subjective changes to implementation approach, etc. is highly undesirable in such a PR because it increases the risk even futher.

Any delta between the Obj-C logic and the Swift logic in this PR should be clearly and directly attributable to a language-specific reason.

If you have subjective disagreements about how the code is currently structured, please feel free to either make prequel PRs or follow-up PRs that make those changes, so they can be discussed, reviewed, and tested in isolation, rather than as part of a complete rewrite of the code.

I am reworking some parts you mentioned again and trying to keep the test mocks as close as possible to how they were before. There are many things I would like to remove, like the factory. While I understand the reasoning behind its use, it's not something I personally prefer. I'm working on this more slowly because I have limited time to dedicate to it.

[stuartmorgan]

There are many things I would like to remove, like the factory. While I understand the reasoning behind its use, it's not something I personally prefer.

As I said in my previous comment:

If you have subjective disagreements about how the code is currently structured, please feel free to either make prequel PRs or follow-up PRs that make those changes, so they can be discussed, reviewed, and tested in isolation, rather than as part of a complete rewrite of the code.

This PR is not the place to make structural changes that are based on your personal preferences.

[Mairramer]

@stuartmorgan I made some adjustments and I'm closer to the Objective-C implementation. There are still a few things left to be done, and if you think it's appropriate, I can mark this PR as a draft and continue working on the remaining details