Example:
ALBS commit: 7afef906 ("Add myself as maintainer")
Tasks download started: 2021-04-05T00:46:44+02:00
Task download finished: 2021-04-05T00:46:51+02:00
Attachments download started: 2021-04-05T00:46:51+02:00
Attachments download finished: 2021-04-05T00:46:51+02:00

The old approach didn't work for the reasons listed in:
5ff17f7c ("Revert "Disable download of attachments by adding a --reject pattern"")

Fix #1

Fixes: 893ce8c1 ("Ignore task hrefs with query parameters for now")

Let's try with 0.05s first.

Ex: https://bugs.archlinux.org/task/69718 which has a link to
https://bugs.archlinux.org/task/69462?string=tt-rss, ideally we should
rewrite it to "69462#string=tt-rss".

This seems to happen when a comment links to a comment in another
task[1].

Before:
20596#comment65592.html
After:
20596.html#comment65592

[1] https://bugs.archlinux.org/task/21194

It does more harm than good:
* Some comment links aren't converted[1]
* Old http://bugs.archlinux.org/task/ links isn't downloaded due to
  --max-redirect 0
* Links with query parameters are downloaded multiple times, ex:
  https://bugs.archlinux.org/task/69462?string=tt-rss from [2]

This reverts commit 94b035d4.

[1] https://bugs.archlinux.org/task/13059
[2] https://bugs.archlinux.org/task/69718

This means we can add "task" to --include-directories and remove the
href="https://bugs.archlinux.org/task/<id>" to "<id>.html" transform
logic as wget is handling it.

So Flyspray (apparently) enjos putting a newline character in the middle
of hrefs which gets translated to "%0A", so let's remove it.

wget only does this if "--include-directories" contains "task"
("download attachment" = true) or if the task was already downloaded
(or is in the url list (not sure)).

Ref #2

The project was moved into the Arch Linux group.

As we are now only processing ~7k tasks per run, I'm not too worried by
its slowness.

Before it would only match if "download attachment" was true and it
would also match other <a> with "https://bugs.archlinux.org".

ALBS_PARALLELIZE_DOWNLOAD=true to enable

It doesn't seem to improve performance just load on bugs.al.org.

One single prettify can use the full CPU core, so there is no reason to
spawn 50 of them.

Fixes: "fatal: 'public' is a missing but already registered worktree;"

It is slow, very slow (~300-400ms per file).

If a task doesn't exist the server returns 302 which wget interprets as
a error due to --max-redirect 0.