Add support for custom socket factory

[mayankvadariya]

Summary

#1391 - Attempt to inject a custom socket factory with APACHE_HTTP_CLIENT connection provider.

Checklist

Delete items not relevant to your PR:

• Unit and integration tests covering the common scenarios were added
• A human-readable description of the changes was provided to include in CHANGELOG
• For significant changes, documentation in https://github.com/ClickHouse/clickhouse-docs was updated with further explanations or tutorials

[CLAassistant]

All committers have signed the CLA.

[mayankvadariya]

@zhicwu I attempted this PR to add support for custom socket factory. Please review the approach and advise for any changes. Thank you!

[zhicwu]

Thank you @mayankvadariya for the pull request! Just some immediate feedback I can think of:

1. Please consider to use more generic names for the new options, for examples: CUSTOM_SOCKET_FACTORY & CUSTOM_SECURE_SOCKET_FACTORY, so that later they can be used in clickhouse-tcp-client as well. Alternatively, we can move the options to ClickHouseHttpOption (better without the http* prefix), so that it's clear that they're just for clickhouse-http-client.
2. Since we're adding new options, in case user wants to use their own extension in an environment like DBeaver, perhaps it's better to try context class loader first, and then parent class loader for loading the custom factory class
3. Does it make sense to reuse existing socket options instead of additional ones for custom socket factory?

[mayankvadariya]

1. Aptly said. Moved the options to ClickHouseHttpOption
2. Please elaborate more on this.
3. It's more about scoping input properties to ClickHouseOption, unknown/unparsed properties are being ignored through driver. Either we can add a way to allow accessing unknown/unparsed properties through ClickHouseOption or add these options. This way custom socket factory doesn't have to depend on the supported parameters by the Clickhouse drivers. Most of the drivers allows access to unknown/unparsed properties when creating a custom socket factory.
   I am also up for getting rid of both options(*_OPTIONS) by making unknown/unparsed input properties somehow available through ClickHouseConfig.

[zhicwu]

2. Please elaborate more on this.

Assume we're using DBeaver, when loading a class, I was thinking maybe it's better to start with the context class loader.
Anyway, let's not worry about this for now. I need to think it through and then probably come up with a separate PR later for the change.

3. It's more about scoping input properties to ClickHouseOption, unknown/unparsed properties are being ignored through driver. Either we can add a way to allow accessing unknown/unparsed properties through ClickHouseOption or add these options. This way custom socket factory doesn't have to depend on the supported parameters by the Clickhouse drivers. Most of the drivers allows access to unknown/unparsed properties when creating a custom socket factory.
   I am also up for getting rid of both options(*_OPTIONS) by making unknown/unparsed input properties somehow available through ClickHouseConfig.

Good point. Perhaps we just need an extra field in ClickHouseConfig for unknown properties. Will make some changes this weekend.

[mayankvadariya]

@zhicwu Did you get any chance to add extra config for getting unknown properties?

[zhicwu]

@zhicwu Did you get any chance to add extra config for getting unknown properties?

Sorry I need someone from ClickHouse team to merge #1403 first to unblock my work, and then I'll be able to make the change and merge other PRs. Let me ping them on Slack.

[mayankvadariya]

@zhicwu we are waiting on this to get merged at the earliest. Do you have any timeline on when this PR might get merged?

[anusudarsan]

@zhicwu any progress on the blocker here?

[zhicwu]

@zhicwu any progress on the blocker here?

Hi @anusudarsan, sorry for the delay. I had meeting with ClickHouse team on Monday - we'll gradually drop gRPC client but keep it for now. I'll fix CI issue and get back to this tonight.

[mzitnik]

@zhicwu any progress on it?

[mayankvadariya]

@zhicwu Checking for the progress on the blockers.

[zhicwu]

Sorry for being super lazy - I was focusing on something else 😂

The initial CI failure has been addressed, but this PR is still failing compilation likely due to moving classes to the http client module. Regarding supporting unknown properties, I plan to complete that this weekend along with two other changes:

1. Stop printing properties in exceptions
2. Support properties with defaults (e.g. new Properties(defaultProps))

[mayankvadariya]

Thanks @zhicwu for checking. I replaced string.formatted with string.format as the CI builds with java8. Please trigger the workflow again.

[zhicwu]

Hi @mayankvadariya, over the weekend, I gave this some thought and believe it would be better to create a generic interface to define custom socket factories. This would allow support for not just Apache HTTP Client but other implementations as well. I've created a separate PR for this approach - see #1420. Please let me know if you have any concerns with this proposal.

[zhicwu]

Close as this will be implemented in #1420.