feat: support per-app proxy configs (e.g. package:native_flutter_proxy)

[zwells]

When running the app on company devices with a custom proxy setting, (using flutter_native_proxy plugin so the app uses the network correctly), the call to the shorebird api fails since it's using its own thread. Is there a way for the plugin/updater to pick up the proxy settings so it can succeed? I've confirmed that the proxy itself is allowing traffic to api.shorebird.dev...

I disabled auto_update and used the plugin thinking maybe it would use the proxy settings after init, but no luck there either. I assume it's due to the nature of the background thread.

I/flutter (20810): [INFO:flutter/shell/common/shorebird/shorebird.cc(148)] Shorebird updater: active path: /data/user/0/com.company.app/files/shorebird_updater/patches/1/dlc.vmcode
I/flutter (20810): updater::updater: Reporting launch start.
I/flutter (20810): updater::cache::patch_manager: No public key provided, skipping signature verification
I/flutter (20810): [INFO:flutter/shell/common/shorebird/shorebird.cc(187)] Shorebird auto_update disabled, not checking for updates.
I/flutter (20810): updater::updater: Reporting successful launch.
I/flutter (20810): proxy enabled using internet.proxy.some-random-company.com:3128
I/flutter (20810): updater::network: Sending patch check request: PatchCheckRequest { app_id: "hidden", channel: "stable", release_version: "4.1.1+4055", platform: "android", arch: "aarch64" }
E/flutter (20810): updater::c_api: Error checking for update: error sending request for url (https://api.shorebird.dev/api/v1/patches/check): operation timed out
E/flutter (20810): 
E/flutter (20810): Caused by:
E/flutter (20810):     operation timed out

[eseidel]

We should add support for this, yes.

[zwells]

I assume it would need to be done at the Rust level if I were to submit a PR for it?

[eseidel]

Sorry, been out sick the last several days, just getting to my inbox now.

https://pub.dev/packages/native_flutter_proxy I presume is the package you're using?

#114 is another way we might tackle this.

It's unclear to me whether we will need to expose some sort of "set proxy" API regardless, or if that need goes away if we were to move onto the platform-native (or at least Flutter-engine-native) networking apis rather than bringing our own.

If we don't need to expose a new "set proxy" api in that case, we should just wait and handle it that way.

If we do need to expose a "set proxy" api regardless, then we could hack something in a the rust layer now and worry about porting it to another networking setup later.

Although I'm unclear as to why apps would set a proxy at all? Isn't that something the User's device typically sets up?

[zwells]

Yes, that's the package.

My app runs on company devices that utilize a private APN sim card with custom settings that cause flutter networking to fail to resolve for some reason until this package is initialized (using company settings).

I would expect #114 would resolve it.

[eseidel]

Thanks. I suspect there are two bugs here.

1. is that Dart networking should probably work out of the box better with your company's network setup. e.g. if a browser works on those devices Dart's networking should too! If you have the energy trying to diagnose/debug a bit and file a bug with Dart would probably be useful long-term.
2. Shorebird's updater needs to have proxy support, implicit or explicit as you note.

[zwells]

Created PR #229.