feat(app-check): add AppCheck implementation

[mikehardy]

Description

Initial implementation of AppCheck module

What works:

• @react-native-firebase/app-check package namespace to match firebase-js-sdk
• appCheck javascript namespace to match firebase-js-sdk
• multi-app support
• debug provider on Android if app is debuggable
• setTokenAutoRefreshEnabled method, and parameter on activate
• getToken in e2e testing works!
• docs

What needs implementing:

• firebase.json entry that toggles FirebaseAppCheckTokenAutoRefreshEnabled plist entry
• token refresh listeners on Android
• some mechanism to configure providers prior to [FIRApp configure] in AppDelegate.m. Maybe we need a startup hook?

I propose that plist entry is deferred as it can be toggled already by early adopters and it's an easy follow-on PR

I prose that refresh listeners on Android are deferred indefinitely, as they don't exist on iOS so would not be cross-platform anyway.

Related issues

#5346

wix/Detox#2933

Release Summary

Each commit is separate and works on it's own with a conventional commit message and comment

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • Yes
• My change supports the following platforms;
  • Android
  • iOS
• My change includes tests;
  • e2e tests added or updated in packages/\*\*/e2e
  • jest tests added or updated in packages/\*\*/__tests__
• I have updated TypeScript types that are affected by my change.
• This is a breaking change;
  • Yes
  • No

Test Plan

• check automaticDataCollection == false to make sure token refresh is disabled
• see if setting automaticDataCollection == false then setting token refresh programmatically works? (the GDPR scenario)

---

Think react-native-firebase is great? Please consider supporting the project with any of the below:

• 👉 Star this repo on GitHub ⭐️
• 👉 Follow React Native Firebase and Invertase on Twitter

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployments, click below or on the icon next to each commit.

react-native-firebase – ./

🔍 Inspect: https://vercel.com/invertase/react-native-firebase/AZM1Gk2Ahz3FrEJ7qx9PgB83seuj
✅ Preview: https://react-native-firebase-git-mikehardy-appcheck-invertase.vercel.app

react-native-firebase-next – ./website_modular

🔍 Inspect: https://vercel.com/invertase/react-native-firebase-next/CGNjRzLnNr7dDz31yNZvmMvob5yj
✅ Preview: Canceled

[Deployment for d7e3c48 canceled]

[codecov]

Codecov Report

Merging #5581 (d8482fb) into master (d4b2015) will decrease coverage by 0.07%.
The diff coverage is 53.34%.

❗ Current head d8482fb differs from pull request most recent head d7e3c48. Consider uploading reports for the commit d7e3c48 to get more accurate results

@@            Coverage Diff             @@
##           master    #5581      +/-   ##
==========================================
- Coverage   71.17%   71.11%   -0.06%     
==========================================
  Files         106      107       +1     
  Lines        4405     4420      +15     
  Branches      941      942       +1     
==========================================
+ Hits         3135     3143       +8     
- Misses       1173     1179       +6     
- Partials       97       98       +1     

[mikehardy]

I checked, there is no AppCheck official logo that I can find.

[numandev1]

@mikehardy I think, we should use JSI for getToken method for reduce getToken time

[mikehardy]

@nomi9995 you think we should require a native build step (that is: NDK for java platforms) and use - for the first time - C/C++ code + makefiles etc + in this module for this API call? With the side effect that since the JSI interface is not stable so we will then have a new per-react-native-version API fragility in the module? Or am I misunderstanding how JSI would be used here? This sounds like a real maintenance headache that I have personally struggled with working with the react-native-reanimated repository and the react-native releases crew - it is a large additional maintenance burden for a module

That said, I'm always open to look at PRs and I do consider performance a feature. Just know that I consider maintainability a feature as well and it is my understanding that use of JSI right now is difficult to maintain

[numandev1]

@mikehardy yes, you are right, JSI is a real maintenance headache and made headache many times in reanimated

[mikehardy]

I'm still open to a PR if you are strongly motivated, react-native-vision-camera uses it without quite as many ill effects, but they ship source vs pre-built binaries and that pushes build time expansion down to consumers.

Honestly I think JSI will be a future direction for the module but it will be used to best effect in Firestore for the document serialization/deserialization where performance really is critical.

For AppCheck, we're just waiting on the SDK to deliver results, I would guess - could be wrong but I would guess - removing JS/native bridge latency from that is an inconsequential modification