`VCRAPI` doesn't record `API._streaming_download()` semantics, including retries

[cfm]

Description

When VCRAPI._send_json_request() returns control to API._send_json_request(), it loses visibility into any downstream semantics, including retry-level request headers and responses.

Steps to Reproduce

With #2329:

1. Run make regenerate-sdk-cassettes.
2. Inspect the last two requests in client/tests/sdk/data/test_download_submission.yml.

Expected Behavior

3. The penultimate request shows the HTTP 416 response.
4. The last request includes a Range header.

Actual Behavior

Both request/response pairs are identical.

Comments

The request is recorded in VCRAPI._send_json_request() and then modified in API._send_json_request() → API._streaming_download().

The HTTP 416 response is resolved in API._streaming_download() and never returned from API._send_json_request(), unlike the HTTP 404 in test_download_submission_stream_404().

[cfm]

This may turn out to be a wontfix: we'd need to instrument API._streaming_download() and possibly Popen, which would interfere with the special Popen used in test_download_submission_autoresume_fail(), which is the motivation for these sub-request semantics in the first place.... After #2329, I would be happy with just documenting this limitation of the test suite.

[eloquence]

Closing; specific to current client implementation, which is undergoing a rewrite.