fix(_streaming_download): handle retry-level JSON error responses

[cfm]

Status

Ready for review.

Description

Fixes #2232 by checking for JSON responses the proxy may have returned midstream in a Range retry, not only at the very beginning of the expected response.

#2330 is a limitation of the test suite I've discovered in the course of this investigation. It's out of the scope of this fix.

Test Plan

• make regenerate-sdk-cassettes succeeds against unparameterized make dev.
  • NB. This is most of this very large diff. Filter to just .py files for easier review!
• Basic smoke-testing of the Client (via this SDK) with any SecureDrop Server.
  • Files can be downloaded.

Checklist

If these changes modify code paths involving cryptography, the opening of files in VMs or network (via the RPC service) traffic, Qubes testing in the staging environment is required. For fine tuning of the graphical user interface, testing in any environment in Qubes is required. Please check as applicable:

• I have tested these changes in the appropriate Qubes environment
• I do not have an appropriate Qubes OS workstation set up (the reviewer will need to test these changes)
• These changes should not need testing in Qubes

If these changes add or remove files other than client code, the AppArmor profile may need to be updated. Please check as applicable:

• I have updated the AppArmor profile
• No update to the AppArmor profile is required for these changes
• I don't know and would appreciate guidance

If these changes modify the database schema, you should include a database migration. Please check as applicable:

• I have written a migration and upgraded a test database based on main and confirmed that the migration is self-contained and applies cleanly
• I have written a migration but have not upgraded a test database based on main and would like the reviewer to do so
• I need help writing a database migration
• No database schema changes are needed

[legoktm]

Should/can we skip this check if bytes_written_prev == 0 (a no-retry request)?

[cfm]

I wondered about this. In terms of control flow:

1. In a retry request:
   1. bytes_written_prev < len(contents) and
   2. bytes_written = len(contents), so
   3. len(partial) < len(contents), so
   4. partial[0:1] != contents[0:1] and is worth checking,
   5. unless we've already returned on line 220.
2. In a non-retry request:
   1. bytes_written_prev = 0 and
   2. bytes_written = len(contents), so
   3. len(partial) == len(contents), so
   4. partial[0:1] == contents[0:1] and is indeed redundant,
   5. unless we've already returned on line 220.

So the "should" here for me comes down to: Is this check too expensive to do twice for a successful request? Probably not. But it is confusing, so let me make it explicit.

[cfm]

Done in c5d0b87. I've kept the conditionals parallel between contents and partial, but let me know if you'd prefer a nested one for partial.