Support sending gzipped request body when uploading

[omarismail94]

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).

Fixes #1988

Description

• Support sending gzipped request body when uploading to the server. Inspired by the recipe in the OKHttp repo to do this
• Make uploading with gzip an option that developers can set
• No need to add code to support download as OkHTTP does this for us automatically
• Tested on local HAPI server and it works

Type
Choose one: (Bug fix | Feature | Documentation | Testing | Code health | Builds | Releases | Other)

Screenshots (if applicable)

Checklist

• I have read and acknowledged the Code of conduct.
• I have read the Contributing page.
• I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
• I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
• I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
• I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
• I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

[aditya-07]

Nice PR @omarismail94 . Left a few comments.

[jingtang10]

Great PR thanks omar!

if you can, please also test on gcp, and if possible, azure, ibm, firely. and knowing the default behavious of all these servers will help us make an informed decision on the default value of the new network config.

[jingtang10]

Great PR thanks omar!

if you can, please also test on gcp, and if possible, azure, ibm, firely. and knowing the default behavious of all these servers will help us make an informed decision on the default value of the new network config.

[omarismail94]

@aditya-07 @jingtang10 resolved all comments

[omarismail94]

I re-ran the benchmark to see how adding content-length influences the time taken to upload and plotted the results below. Yes, it does increase at a faster rate as more data is compressed, but I think for now, this is OK. Even if we do upgrade to the OkHttp library that adds the content length for us, it does so in the same way we do, so we would face the same issue. The alternative is to have the gzip interceptor after the HttpLoggingInterceptor, however, that would mean the LoggingInterceptor would be printing the content-length of the uncompressed request