ad mTLS support for Android

[deep2web]

fixes #39 (#35)

Adds support for mTLS (Mutual TLS) client certificate authentication on Android. This allows users to connect to evcc instances that are secured behind a reverse proxy requiring client certificates.

• Adds a native Expo module (client-cert) to store and provide PKCS#12 client certificates (IMHO using android system keystore would be more complicated and not ideal regarding an future iOS implementation) .
• Patches react-native-webview on Android to intercept onReceivedClientCertRequest and inject the stored certificate.
• Adds UI to the server configuration form (Android only) to select a .p12/.pfx file and provide its password.
• Limits the mTLS UI to Android, as iOS native WebView interception for mTLS is not yet implemented.

I think there's currently no other option than to patch react-native-webview, since the maintainer there isn't currently planning to implement it as a feature and instead refers to this example: https://github.com/diebietse/mtls-android/tree/master/app/src/main/java/com/diebietse/mtlsandroidexample, which also helped me a bit with this PR (see react-native-webview/react-native-webview#2857)

[Maschga]

I'd like to keep the client-cert module out of this repo.
For a clean solution we should fork the react-native-webview repo and patch it directly.

[deep2web]

@Maschga Yeah, that's probably true. I also don't really feel comfortable adding all the code to the app myself, since that's also may be a bit confusing. If I have time at some point, I might try to create a fork of react-native-webview.
Another advantage would be that, in the event of a fork, other users of react-native-webview could theoretically us it as well.
However, I'm having a few issues adding the feature on iOS (in principle, it should be possible there as well), since, on the one hand, I have less experience with it, and on the other hand, I can't test it very well on Windows or Linux (although I have an iPad but building is a mess).

[Maschga]

I suggest you try it out locally with your fork first, and if everything works, a fork can be created at the evcc level.

It would probably be best if you got the feature working on Android first and then added tests using Caddy. These tests can then also be used to test the feature on iOS.

[naltatis]

Since react-native-webview is the centerpiece of the evcc I would stay on the official release of this dependency - no patches or forks. Once officially support for this lands in the react-native-webview project we can address this here. We have similar outstanding issues with custom headers and iOS support for self-signed certs. Going the patch/fork route would make us responsible for maintaining or at least understanding the intricate details of Android/iOS browser integration.