fix(deps): bump requests-toolbelt to fix deprecation warning

[nejch]

Closes #2263

[lmilbaum]

@nejch Does it make sense to add a test that verifies the warning is no longer present?

[nejch]

@nejch Does it make sense to add a test that verifies the warning is no longer present?

@lmilbaum the warning was reported here due to upstream inactivity, but actually coming from a transitive dependency (urllib3) via another dependency (requests-toolbelt). It was fixed in that release, so I think a test should be upstream in toolbelt rather than in the scope of our library (maybe this was already done in requests/toolbelt#336). Unless I misunderstood and you meant a more general test for deprecation warnings (not sure if that's feasible, deprecation warnings do happen).

In any case this is a very minor issue, we do not restrict a maximum version of requests-toolbelt, so users are free to upgrade already on their own (and if they don't pin transitive dependencies in lockfiles then they probably are already on the latest version). Hope that makes sense :)

[lmilbaum]

@nejch Does it make sense to add a test that verifies the warning is no longer present?

@lmilbaum the warning was reported here due to upstream inactivity, but actually coming from a transitive dependency (urllib3) via another dependency (requests-toolbelt). It was fixed in that release, so I think a test should be upstream in toolbelt rather than in the scope of our library (maybe this was already done in requests/toolbelt#336). Unless I misunderstood and you meant a more general test for deprecation warnings (not sure if that's feasible, deprecation warnings do happen).

In any case this is a very minor issue, we do not restrict a maximum version of requests-toolbelt, so users are free to upgrade already on their own (and if they don't pin transitive dependencies in lockfiles then they probably are already on the latest version). Hope that makes sense :)

Totally makes sense. Thanks for the clarification.