Support implementations that do not require authorization for the get_object endpoint

[ianfore]

For objects that require authorization...

Many DRS implementations do not require authorization for get_object. Authorization is only needed when obtained the url at which to download bytes.

This applies to all the gen3 DRS implementations (crdc, topmed, etc.) and to the NCBI implementation.

The compliance suite appears to apply authentication to the get_objects request i.e. the get /objects/ end point.

The first result set (drs_compliance_report2.txt) shows the test report for the NCBI DRS with "auth_type": "passport"
This fails the "drs object info" phase because authentication is being applied to the request. The server does not expect auth to be passed for this request.

The second result run (drs_compliance_report2.txt) used the same drs ids with with "auth_type": "none"
The responses for the ids pass most tests
(the issue with the NCBI implementation providing self_uri as self_url is a separate issue and will be dealt with by the implementation)
It of course fails the "drs object access" phase with a 401 when it attempts to get the url for the object.

The compliance suite should support applying auth only to the object access phase in such a scenario.

Note that some implementations require auth for both phases. The compliance suite will need to handle both scenarios.

The attached .txt files are json, but the json extension was not supported during file upload to GitHub.

drs_compliance_report2.txt
drs_compliance_report3.txt

[ianfore]

Also adding the config files used for the two reports above.
Note that the tokens have been disabled by editing them.
ncbi_config2.txt
ncbi_config3.txt

[ianfore]

Reran with the latest update.
Required significant modification of the config file to specify that auth was not needed for get_object.
The test ran OK with a suitably configured config file.

However, the config file is now more cumbersome to edit - with a lot of duplication.

The following config would be more compact.
In fact, the simpler default would be that if auth_get_object was not present in the config file that it would be assumed to be false. This is the more common scenario.
If auth is required on get_object then it would have to be present in the config_file.

 "drs_objects" : [
   {
      "drs_id" : "47065fa87f3ac9f58426d4157ab281de",
      "auth_type": "passport",
      "auth_token": ["token-xyz"],
      "auth_get_object": false,
      "is_bundle": false
   },
   {
      "drs_id" : "0000cc2f56847afb9a238a05c6c7747c",
      "auth_type": "passport",
      "auth_token": ["token-xyz"],
      "auth_get_object": false,
      "is_bundle": true
   }
 ]

[ianfore]

The following might also be considered which provides auth which would be used for all the objects in the test. This would be a practical simplification and would work for most of the common existing DRS services. If necessary, auth details could be provided at an object level. If absent the auth_config would be used. In most cases only auth_config would be needed.

"auth_config"  :  {
      "auth_type": "passport",
      "auth_token": ["token-xyz"],
      "auth_get_object": false
},
"drs_objects" : [
   {
      "drs_id" : "47065fa87f3ac9f58426d4157ab281de",
      "is_bundle": false
   },
   {
      "drs_id" : "0000cc2f56847afb9a238a05c6c7747c",
      "is_bundle": true
   }
 ]