Add encryptionScheme parameter to htsget

[brainstorm]

This is a non-breaking, optional change for htsget.

This is already supported as experimental feature in htsget-rs since umccr/htsget-rs#298. It specifically allows for Crypt4GH requests for each underlying bioinformatics format.

There's also the corresponding work in progress in htsget-compliance testsuite to support this extra parameter/schemes in ga4gh/htsget-compliance#11.

/cc @ohofmann @mmalenic @mlin @jppay

[daviesrob]

How exactly are you implementing crypt4gh in htsget-rs?

There's basically two ways you could do it - either encrypt each segment linked in the htsget response separately, or have them all join together to make a single encrypted file. HTSlib has historically supported the latter, and also looks for the magic number so it can tell an encrypted payload apart from a plain one without having to make any changes to the htsget specification.

[mmalenic]

How exactly are you implementing crypt4gh in htsget-rs?

It's implemented by joining segments together into a single encrypted file. It calculates the bytes to return to the client, and then re-encrypts the Crypt4GH header and adds an edit list packet using a configured public/private key pair.

and also looks for the magic number so it can tell an encrypted payload apart from a plain one without having to make any changes to the htsget specification.

This works, however the encryptionScheme parameter is non-breaking and optional, and I think it would clearer and more practical for the client.

The advantage of adding an additional parameter is that it allows the client to directly request encrypted or non-encrypted files without having to inspect the response header type. I think this lines up with the logic of specifying CRAM/BAM or BCF/VCF in the format parameter. It also allows the client to request encrypted or non-encrypted data for the same <id>.

Similar discussion to #581, where clients can give hints on the data they are expecting to make their logic easier.