Add Support HTTP compression

[bgunebakan]

Adds opt-in HTTP compression support to the crate-python driver to reduce bandwidth usage and improve performance for large queries.

Summary of the changes / Why this is an improvement

• Client-side request compression (compress_client, default: True). Outgoing JSON request bodies are gzip-compressed before being sent.
• Server-side response compression (compress_server, default: False). The driver sends Accept-Encoding: gzip, deflate to CrateDB server when it's enabled.
• Compression is skipped for payloads below compress_threshold bytes (default 8192)
• 6 new unit tests covering: compression disabled, compression enabled, below-threshold skip, Accept-Encoding sent/not sent, and default-args behavior.

Small note on threshold default value:

I've changed compress_threshold to 8192 while implementing. I ran a payload-size sweep against both a local CrateDB instance and a CrateDB Cloud cluster (eu-west-1 free tier), measuring round-trip latency with and without gzip compression. I saw benefits of compression when latency included over 8kb on local and 1kb on cloud instances.

Latency can vary based on my network and cluster settings/location. I decided to move on 8kb as a default value for threshold.

Checklist

• Link to issue this PR refers to (if applicable): Fixes Support HTTP compression #700
• Added or Changed code is covered by tests
• Updated documentation & CHANGES.rst

[mfussenegger]

• I think we can remove the compress_server setting and always set the header leaving it up to the server - given that in CrateDB compression also needs to be enabled with default being off.
• I'd also remove the compress_algorithm setting - given that there is so far only gzip supported there's no point in the setting
• I'd tend to merge compress_client / compress_threshold to a single setting:
  • number: Compressed if payload body > the number
  • bool true: Always compressed
  • bool false: Never compressed
    Otherwise the interaction between enabled/threshold seems more ambiguous and also sort of redundant to have both separate.

Didn't look into the details yet

[bgunebakan]

Thanks for your review!

• I think we can remove the compress_server setting and always set the header leaving it up to the server - given that in CrateDB compression also needs to be enabled with default being off.

Agree to remove it and always send Accept-Encoding: gzip, deflate. I had it as an opt-in partly out of caution around BREACH, but we can leave this control to server config.

• I'd also remove the compress_algorithm setting - given that there is so far only gzip supported there's no point in the setting

Agree to remove it if there is no plan to implement other algorithms.

• I'd tend to merge compress_client / compress_threshold to a single setting:

  • number: Compressed if payload body > the number
  • bool true: Always compressed
  • bool false: Never compressed
    Otherwise the interaction between enabled/threshold seems more ambiguous and also sort of redundant to have both separate.

Didn't look into the details yet

Make sense to merge compress parameters. The type check needs to test for bool before int, otherwise compress=True would be interpreted as threshold 1.

[mfussenegger]

Left some minor suggestions, otherwise lgtm

[mfussenegger]

Suggested change

	compress=8192,
	compress: Union[int, bool] = 8192,

I think it would be good if we started adding type annotations - at least for the public API

[bgunebakan]

I added types, I'd like to tackle all annotations in separate PR. I needed to add for _inactive_servers and server_pool because mypy were complaining.

[mfussenegger]

Suggested change

	compress_enabled = self.compress is True or (
	not isinstance(self.compress, bool) and len(data) >= self.compress
	)
	compress_enabled = self.compress is True or (
	isinstance(self.compress, int) and len(data) >= self.compress
	)

Or might even make it stricter and fail if it's neither bool nor int.

[bgunebakan]

I added check in __init__ and will fail if it's not int or bool