feat: create local proxy library that is Go Mobile-friendly

[fortuna]

In this PR:

• Add x/appproxy library that runs a local proxy given an address and config
• Add x/examples/fetch-proxy that illustrates the pattern of running a local proxy and configuring a networking library.
• Fix web proxy handler to support regular web proxy requests. The fetch-proxy wouldn't work for HTTP pages otherwise.
• Add x/examples/mobileproxy, which illustrates how to build the local proxy library for mobile.

[jyyi1]

Thanks, added some comments.

[jyyi1]

Do we really need this? It seems we don't have any actual code generating this folder, the only place we mentioned it is in the document. I feel it's OK to un-track it if it's only generated in a documentation, and we already mentioned how to clean it up in the doc.

[fortuna]

Another look?

[fortuna]

What do you think about moving this to x/appproxy and call it x/mobileproxy, so it's clear it's for Go Mobile?

x/appproxy shouldn't really be used by Go code, since it has a limited API that is not really optimal for Go.

[fortuna]

FYI, I updated the PR to have everything in x/mobileproxy. This way we can keep the library as clearly intended for Go Mobile.

[daniellacosse]

should we add a TODO to publish these to Swift packages/maven?

[jyyi1]

👍 Providing a wrapper library would be better than documentation.

[fortuna]

That is definitely something that will help and we should consider. The downside is that it will require a releases process. Let's see how people end up using it and think about where we would put the binaries. To be defined.

[daniellacosse]

Yeah, that's why I said we should at least track it with a TODO, or maybe an issue.

[fortuna]

For now, I don't want to set the expectation that we will be providing the pre-packaged libraries. I want to see if what we have here will be good enough first, and we can consider the next step if people keep struggling.

[daniellacosse]

Is every TODO or thing in the backlog something we're committing to definitely doing?

[fortuna]

The reason for not having a TODO for the release is that we are not currently intending to do it. Adding a TODO to a README file will set the wrong expectation. It's different from a code TODO.

We've been keeping the roadmap in the root README.

[daniellacosse]

It's unclear to me why this is in here. Won't this diverge?

[fortuna]

The goal is to make it clearer what the actual mobile interfaces look like, since that's what people will be using. It clarifies what the output is too.

It shouldn't diverge if we don't change the API.

[daniellacosse]

Sure, but why not commit the files and then just link to them? And generate them in pre-commit?

[fortuna]

Committing generated code is generally bad practice, as it diverges and it's hard to tell where the generated file came from. The releases, if we decide to do them, will include the binaries and header files.

The goal of having the code here is educational, so people know what the native library looks like.

[daniellacosse]

But you're committing generated code here? Why is it okay when you do it?

[fortuna]

That's just for illustration, it's not code to be used. People won't be copying and pasting it. They will run the commands in the README instead.

I've updated the text to say "Sample" code to make it clear that may not be the actual code to be used.

[jyyi1]

Or maybe adding "for reference", or "do not use in production" warning before the code snippet would make it more clear?

[fortuna]

Added a comment and a warning.

Note that there's no risk in accidentally using this in production, since you actually need the XCFramework/AAR with the binaries in it.

[jyyi1]

Thanks, the code looks good, added a few nit-picking comments.

[jyyi1]

👍 Providing a wrapper library would be better than documentation.