refactor!: remove FCM dependency from cocoapods

[levibostian]

Breaking change introduced:

• Customers impacted: React Native customers using FCM. That's because if they follow our docs as they appear today, we do not tell customers to install Firebase dependencies on their own with cocoapods. So, by RN customers upgrading the iOS SDK to include this change, they will need to install the firebase SDK themselves.

Needs to be tested: done

• Create new iOS app that uses cocoapods
• Install this PR
• Integrate FCM
• Run app and see if receive a rich push

This PR fixes this customer reported issue. Our original action item was to update the Firebase dependency in our iOS SDK. However, after evaluation, I determined that our code doesn't not actually reference anything from Firebase at this time. Our SPM config files do not contain any Firebase dependency items at all. So, I removed the dependency to fix this customer issue.

Maybe the Firebase dependency was originally added for react native? If so, I assume that the react native can declare FCM as a dependency in itself instead of inheriting the FCM dependency from the CIO iOS SDK.

[ami-oss-ci]

Pull request title looks good 👍!

If this pull request gets merged, it will cause a new release of the software. Example: If this project's latest release version is 1.0.0. If this pull request gets merged in, the next release of this project will be 2.0.0. This pull request is a breaking change.

All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time.

To merge this pull request, add the label Ready to merge to this pull request and I'll merge it for you.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy!

This pull request title should be in this format:

<type>: short description of change being made

If your pull request introduces breaking changes to the code, use this format:

<type>!: short description of breaking change

where <type> is one of the following:

• feat: - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project.

• fix: - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project.

• docs: - This pull request is making documentation changes, only.

• refactor: - A change was made that doesn't fix a bug or add a feature.

• test: - Adds missing tests or fixes broken tests.

• style: - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc)

• perf: - Changes improve performance of the code.

• build: - Changes to the build system (maven, npm, gulp, etc)

• ci: - Changes to the CI build system (Travis, GitHub Actions, Circle, etc)

• chore: - Other changes to project that don't modify source code or test files.

• revert: - Reverts a previous commit that was made.

Examples:

feat: edit profile photo
refactor!: remove deprecated v1 endpoints
build: update npm dependencies
style: run formatter 

Need more examples? Want to learn more about this format? Check out the official docs.

Note: If your pull request does multiple things such as adding a feature and makes changes to the CI server and fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

[levibostian]

Blocked from merging until testing is done.

[codecov]

Codecov Report

Merging #210 (6e6611e) into main (d44c58a) will decrease coverage by 1.21%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #210      +/-   ##
==========================================
- Coverage   52.30%   51.09%   -1.22%     
==========================================
  Files         101      101              
  Lines        1172     1742     +570     
==========================================
+ Hits          613      890     +277     
- Misses        559      852     +293     

Impacted Files	Coverage Δ
Sources/Common/Background Queue/QueueRunner.swift	66.66% <0.00%> (-13.34%)	⬇️
...es/MessagingPush/MessagingPushImplementation.swift	41.66% <0.00%> (-8.34%)	⬇️
...ngInApp/autogenerated/AutoMockable.generated.swift	67.74% <0.00%> (-4.49%)	⬇️
...PushAPN/autogenerated/AutoMockable.generated.swift	27.50% <0.00%> (-4.32%)	⬇️
...PushFCM/autogenerated/AutoMockable.generated.swift	27.50% <0.00%> (-4.32%)	⬇️
Sources/Common/Background Queue/Queue.swift	61.90% <0.00%> (-2.39%)	⬇️
Sources/MessagingPushAPN/MessagingPushAPN.swift	8.33% <0.00%> (-1.67%)	⬇️
Sources/MessagingPushFCM/MessagingPushFCM.swift	8.33% <0.00%> (-1.67%)	⬇️
Sources/Common/Util/Mocks.swift	100.00% <0.00%> (ø)
Sources/Common/Type/SDKWrapperConfig.swift	100.00% <0.00%> (ø)
... and 11 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[levibostian]

Unblocked as I completed testing. I created a new iOS app > Installed this PR > Got a FCM token and sent the token to a profile in CIO.

[jatinn]

you mention the dependency may have been for react native so we should also test with a build of the ios react native app using fcm just to confirm

[jatinn]

change is straightforward but lets test with the react native/expo ios fcm test app to ensure no impact or to document the extra config steps that may be needed due to this pr being merged

[levibostian]

Currently blocked while PR gets tested in Ami app to see if RN SDK is impacted by this change.

Learn more: https://customerio.slack.com/archives/C01QYDKD0SU/p1667939161080969

[levibostian]

Keeping branch available so workaround continues to work

[ami-ci]

🎉 This PR is included in version 2.0.0-alpha.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀