Add support for HApp subscription URLs

[ofry]

Summary

Add support for HApp subscription URLs in PassWall2.

Some VPN services provide subscription links in the happ://crypt* format, which cannot be downloaded directly by PassWall2 as a regular HTTP/HTTPS URL.

This change adds transparent preprocessing for HApp subscription URLs:

1. When the subscription URL starts with happ://crypt*, PassWall2 sends it to the HApp resolver API.
2. The resolver request uses the same access mode selected for the subscription (direct, proxy, or auto).
3. The resolver response is stored in a temporary file and read as a plain HTTP/HTTPS subscription URL.
4. The temporary file is removed after processing.
5. The resolved URL is then passed through the existing subscription download and parsing logic.

Regular http:// and https:// subscription URLs are handled exactly as before.

Implementation

The HApp URL preprocessing is implemented in subscribe.lua and integrated into the existing curl() subscription download path.

The resolver uses the existing PassWall2 API functions:

• api.curl_direct()
• api.curl_proxy()
• api.curl_auto()

This ensures that resolving an HApp subscription follows the same network access mode as downloading the resulting subscription.

Testing

Tested with a real HApp happ://crypt4/... subscription URL.

Verified that:

• the HApp URL is resolved successfully;
• the resolver request works with the selected access mode;
• the resulting HTTP/HTTPS subscription URL is downloaded by the existing PassWall2 subscription pipeline;
• the resulting nodes are imported normally;
• regular HTTP/HTTPS subscription URLs continue to use the existing code path.

Related to #1167.

[ofry]

@handsomeji I added such PR.

Could you review it?

[ofry]

Synced with latest upstream.

@handsomeji Could you review it?

[handsomeji]

Sorry, I don't plan to merge this PR. This commit uses a third-party API for parsing. And this feature requirement is not in the plan.

[ofry]

@handsomeji
Thanks for the clarification.

I understand that the current PR is not acceptable because it relies on a third-party API and HApp support is currently not in the plan.

Before I proceed with any changes, could you please clarify the preferred direction?

Would any of the following approaches be acceptable?

1. Minimal opt-in implementation:
   add a checkbox to the subscription configuration such as
   "Allow external API to resolve HApp subscription URLs".

   When enabled, happ://crypt* URLs would be resolved through an
   external API before the existing subscription download pipeline.
   Regular HTTP/HTTPS subscriptions would remain completely unchanged.

2. Native implementation:
   HApp subscription URLs should be decrypted locally on the router,
   without relying on any third-party service.

3. HApp subscription support itself is not acceptable / not planned,
   regardless of whether the implementation is local or uses an external API.

Which of these directions, if any, would be acceptable for PassWall2?