Expected output in testcases do not follow spec encoding

[petergardfjall]

This test case states that given input

pkg:generic/openssl@1.1.10g?download_url=https://openssl.org/source/openssl-1.1.0g.tar.gz&checksum=sha256:de4d501267da

the expected output is

pkg:generic/openssl@1.1.10g?checksum=sha256:de4d501267da&download_url=https://openssl.org/source/openssl-1.1.0g.tar.gz

I think this does not follow the canonical purl encoding which (correct me if I'm wrong!) should be:

pkg:generic/openssl@1.1.10g?checksum=sha256:de4d501267da&download_url=https:%2F%2Fopenssl.org%2Fsource%2Fopenssl-1.1.0g.tar.gz

The same is true for a number of download_url qualifiers in other test cases:

• hex-test.json
• huggingface-test.json
• luarocks-test.json
• maven-test.json
• mlflow-test.json
• npm-test.json
• oci-test.json

Or are library implementations required to preserve the original user input (encoding, qualifier ordering, etc) purl and have a separate method/function to return the canonical purl?