avoid task id collisions for urls FilterQueryParams cannot parse

[saddamr3e]

Description

FilterQueryParams rebuilds the query from u.Query(), which keeps only the pairs
url.ParseQuery could decode and throws the error away, so ?foo=%zz and ?foo=%yy
both canonicalize to https://example.com. On the error path both idgen helpers
substituted "", so every url that fails url.Parse hashes to SHA256(""):

--- FAIL: TestTaskIDV1/generate_taskID_with_undecodable_query_param
    Error: Should not be: "100680ad546ce6a577f42f52df33b4cfdca756859e664b8d7de329b150d09ce9"
--- FAIL: TestTaskIDV1/generate_taskID_with_unparsable_url
    Error: Should not be: "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"

Parse the raw query directly so the error reaches the caller, and keep the raw url in
taskIDV1 / TaskIDV2ByURLBased when filtering fails.

Related Issue

N/A

Motivation and Context

The scheduler recomputes the task id server side from the peer-supplied url
(scheduler/rpcserver/scheduler_server_v1.go:56, and the TaskIDV2ByURLBased calls in
scheduler/service/service_v2.go), so two peers requesting different urls that collide
on one id get put on the same task and can be served each other's pieces.

Both triggers are ordinary fetchable urls, not just malformed ones: an invalid percent
escape such as ?discount=100%, and ; separated params, which ParseQuery has
rejected since Go 1.17. Neither reaches the sink through a caller that could pre-validate,
since the id is derived inside these helpers.

Task ids for well-formed urls are unchanged. u.Query() is ParseQuery(u.RawQuery) with
the error dropped, so the filtering path is identical when the query decodes, and the
fixed-hash cases already in task_id_test.go still pass. A url that now fails to filter
keeps its signature query params in the id, which costs deduplication for that url rather
than merging it with an unrelated one.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation Update (if none of the other choices apply)

Checklist

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 28.47%. Comparing base (c9e2e6d) to head (35b7d74).
⚠️ Report is 58 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4912      +/-   ##
==========================================
+ Coverage   28.08%   28.47%   +0.39%     
==========================================
  Files         232      235       +3     
  Lines       23153    23238      +85     
==========================================
+ Hits         6502     6618     +116     
+ Misses      16211    16172      -39     
- Partials      440      448       +8     

Flag	Coverage Δ
unittests	28.47% <100.00%> (+0.39%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
pkg/idgen/task_id.go	89.18% <100.00%> (+8.23%)	⬆️
pkg/net/url/url.go	100.00% <100.00%> (ø)

... and 39 files with indirect coverage changes

🚀 New features to boost your workflow:

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