(iOS/Android): avoid collection state getting out of sync, remove restriction to override plist defaults

[DavidStrausz]

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Documentation changes
• Other... Please describe:

PR Checklist

For bug fixes / features, please check if your PR fulfills the following requirements:

• Testing has been carried out for the changes have been added
• Regression testing has been carried out for existing functionality
• Docs have been added / updated

What is the purpose of this PR?

Currently it is possible for the 3 collections (analytics collection, performance collection, crashlytics collection) to get into an inconsistent state.
This is possible because when setting the flags an error is thrown if the plugins own state already matches the value the user would like to set (e.g. "Analytics data collection is already set to enabled"). However it is possible the Firebase SDK was already used before the plist config flags were introduced which could lead to the following scenario:

• In the old SDK the user has enabled the analytics collection (SDK is in state enabled, no plist config yet) ✅
• App is updated to new plugin version with all three plist flags set to true (SDK and plugin are in state enabled) ✅
• App developer implements GDPR requirements and all three collections are now opt-in
• App is updated and all three plist flags are set to false (SDK is in state disabled but plugin stays in state enabled) ❌
• If the user now enables one of the flags the plugin returns an error as the local plugin state indicates it is already enabled whereas in fact it is not (the SDK strictly follows the plist flags). ❌

I understand the plugins local state was added to provide information about the state, which is not exposed by the SDK itself, so it the plugins own state cannot be removed completely.

This PR removes the logic which prevents the users setting from being set directly in the SDK. This solves the above mentioned scenario (and other variations of it) and also keeps the ability to provide info about the current state.

Update:
In my followup commits I also did the same changes for Android and I also removed the check which does not allow to override the plist default values if they are set to true. This way developers can also offer an "opt-out" scenario, where data-collection is enabled by default and can be disabled by the user on-demand.

I also checked the firebase documentation and it also says that always the SDK preference takes precedence over the plist config:

The value set by the setAnalyticsCollectionEnabled method persists across app executions and overrides the value for FIREBASE_ANALYTICS_COLLECTION_ENABLED in your app's Info.plist file.

Which is why I don't really see the reasoning behind these checks in the plugin.

Does this PR introduce a breaking change?

• Yes
• No

What testing has been done on the changes in the PR?

Enabling/disabling the three collections. Test different combinations of old SDK and then updating to the new SDK, changing plist flags them again enabling/disabling the flags.

What testing has been done on existing functionality?

Tested in our in-house projects which all use the firebase plugin - no regressions so far.