downloader: fix SAS token corruption in constructDatastoreContext

[jsfakian]

Description

url.JoinPath() percent-encodes ? to %3F when it appears inside
a path segment argument. When configName contains a query string
(e.g. an Azure SAS token: ?st=...&se=...&sig=...), the entire query
string is mangled into the path, causing Azure Blob Storage to return
HTTP 409 on the resulting URL, leaving the app instance permanently
stuck in DOWNLOADING state.

Split configName on the first ? before calling url.JoinPath,
apply the path join only to the clean path portion, then reattach the
raw query string after assembly. This preserves SAS tokens and any
other query-string credentials embedded in the relative URL.

The regression was introduced when simple string concatenation was
replaced with url.JoinPath (13.4-stable → 16.7.0). The old
concatenation preserved ? literally; url.JoinPath correctly
encodes it as a path character, breaking datastores configured as HTTP
type with a SAS-bearing relative URL.

How to test and validate this PR

Prerequisites:

• A device running EVE 16.x
• A Zededa controller with an application configured to use an HTTP
  datastore pointing to Azure Blob Storage, where the relative URL
  contains a SAS token (i.e., the URL contains ?st=...&sig=...)

Steps to verify the fix:

1. Apply this patch and build EVE
2. Run the device with EVE that includes the patch
3. Onboard the device on a controller with an application configured to use an HTTP
   datastore pointing to Azure Blob Storage, where the relative URL
   contains a SAS token (i.e., the URL contains ?st=...&sig=...)
4. The download should proceed successfully — no HTTP 409, no %3F in
   the logged URL, CurrentSize increments in the downloader status
5. The app instance should progress past DOWNLOADING to RUNNING.

Changelog notes

Fixed a regression introduced in 16.0, where application image downloads
from HTTP datastores using Azure SAS tokens (query string credentials
in the relative URL field) failed with HTTP 409, leaving the application
permanently stuck in the DOWNLOADING state. The fix correctly
preserves the SAS query string when constructing the download URL.

PR Backports

• 16.0-stable: Yes.
• 14.5-stable: Yes.
• 13.4-stable: No, same reason as 14.5-stable.

Checklist

• I've provided a proper description
• I've added the proper documentation
• I've tested my PR on amd64 device
• I've tested my PR on arm64 device
• I've written the test verification instructions
• I've set the proper labels to this PR
• I've checked the boxes above, or I've provided a good reason why I didn't
  check them.

[rene]

LGTM

[milan-zededa]

The caller is responsible for passing a correctly percent-encoded query string in configName.

Is the caller here the controller or the user? In the latter case, we should make sure this requirement is documented.

[eriknordmark]

Needs to be rebased on master for the eden tests to work

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 28.34%. Comparing base (2281599) to head (ac8396d).
⚠️ Report is 468 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5715      +/-   ##
==========================================
+ Coverage   19.52%   28.34%   +8.81%     
==========================================
  Files          19       18       -1     
  Lines        3021     2417     -604     
==========================================
+ Hits          590      685      +95     
+ Misses       2310     1588     -722     
- Partials      121      144      +23     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[europaul]

@jsfakian this bug is coming from my PR #5588, which I also backported to 14.5
so I think the fix should be backported as well

[rene]

Updates:

• Rebased on top of master

[europaul]

@jsfakian please take another look at the backporting section - I think this fix needs to be marked as stable and backported
Also see my previous comment #5715 (comment)

[europaul]

@jsfakian I backported the fix to 16.0-stable, but 14.5 and 13.4 still need to be done

[jsfakian]

@jsfakian I backported the fix to 16.0-stable, but 14.5 and 13.4 still need to be done

Thank you, @europaul. 13.4 has the old code, so there is no need to backport it there. I can prepare the backport for 14.5