Remove Lottie

[mokagio]

Remove the Lottie third-party library and the screens using it.

These screens were no longer used by the client apps, so the removal is "safe".

Nevertheless, I bumped the major version to represent the breaking change from dropping the Lottie library and consequently removing the UIViewController using it.

Hat tip @jkmassel for having done most of the work already. 🎩

See, both with green unit tests:

• Update WordPress Authenticator to remove Lottie dependency woocommerce/woocommerce-ios#6379
• Update WordPress Authenticator to remove Lottie dependency WordPress-iOS#18109

[mokagio]

Unfortunately, LoginPrologueViewController is required in the codebase despite being used directly by the clients of this library. The reason is that the Login storyboard uses it. Without it, the storyboard fails to decode. I originally removed it but had to put it back and didn't feel it granted a git revert -n dance, which is why it looks moved here.

I think there's space for way more files removal, but I don't want to go overboard with this PR.

I also think it would be fine to ship this as 2.0.0 and then remove more files, even though that might consist as another breaking change. After all, we are the only consumers of this library, and the successful tests done for this PR shows the old login flow code is unused. Also, even though I haven't checked, I'd assume most if not all of the code now removable would be internal. Removing that wouldn't affect clients.

[AliSoftware]

Overall looks good, but left some very small suggestions for pbxproj format update and use of deprecation annotation; take it or leave it.

[AliSoftware]

Worth updating the pbxproj's project format version to a more recent one so that it supports using xcfilelist (making CocoaPods then use them and have those changes be outside of the pbxproj)?

Maybe for a separate PR though (similar to the idea you floated around about removing more files later… though the change in pbxproj format would not be a breaking one, so could be worth doing befor a new major version bump…? 🤷 )

[mokagio]

Oh good point. Thanks. I'll do that in a dedicated PR, to isolated that project structure change.

[AliSoftware]

Suggested change

	// This property is a legacy of the previous UX iteration. It ought to be removed, but that's
	// out of scope at the time of writing. It's now `private` to prevent using it within the
	// library in the meantime
	@objc private var pages: [UIViewController] = []
	@available(*, deprecated, message: "This property is a legacy of the previous UX iteration and ought to be removed (but that was out of scope at the time of writing).")
	// Property is `private` to prevent using it within the library in the meantime, see deprecation message above
	@objc private var pages: [UIViewController] = []

[mokagio]

That's a nice idea, thanks.

I tried it locally, and got a lot (well, 10) warnings:

All the warnings in the mini map are because of the deprecated page.

Part of me welcomes them. "Yes! Make some noise in the build so we get rid of dead code ASAP." Another part of me doesn't want them because, while it's true that we ought to get rid of that code, there's no pressing necessity to do it and I wouldn't want other, legit warnings to get lost among them.

Currently, I'm leaning toward not throwing the warnings, so I'm going to merge as is. Happy to revisit, though.