BREAKING CHANGE: Create a `Sender` or `SenderBuilder` from configuration or env var (#54)

[amunra]

Overview

The aim here is to support the new ILP config string format as documented in https://docs.google.com/document/d/1EQZjYrJO_Ll8RrSIZpbr15Ul3N-xAtTxvrunI-TpOR8 and now also supported by the Java client and soon other clients too.

Changes

This introduces a new "configuration string" format that is being supported across all ILP clients.

The parser was already implemented as https://github.com/questdb/questdb-confstr-rs/.

The format is: protocol::addr=host:port;key1=value1;key2=value2;...;.

The protocols supported are:

• tcp
• tcps (with TLS)
• http
• https (with TLS)

The Rust SenderBuilder, and the C and C++ opts object methods have been aligned to the new configuration format.

For example in C++,

// OLD API
line_sender_builder opts{"localhost", 9009};
opts.auth("u", "t", "x", "y"); 

has been refactored to:

// NEW API
line_sender_builder opts{protocol::tcp, "localhost", 9009};
opts.username("u");
opts.token("t");
opts.token_x("x");
opts.token_y("y");

and is now equivalent to the conf string

tcp::addr=localhost:9009;username=u;token=t;token_x=x;token_y=y

and can now support building directly without the opts object:

auto sender = line_sender::from_conf(
    "tcp::addr=localhost:9009;username=u;token=t;token_x=x;token_y=y");

The config string can also be read from an environment variable:

export QDB_CONF_STR="tcp::addr=localhost:9009;username=u;token=t;token_x=x;token_y=y"

auto sender = line_sender::from_env();

HTTP

The config string can also be used to configure HTTP.

This is what creating a Rust client with HTTP+TLS looks like:

let sender = Sender::from_conf("https::addr=localhost:9000;username=admin;password=quest;");

For HTTP authentication you can also use a token:

let sender = Sender::from_conf("https::addr=localhost:9000;token=abc;");

Progress

• [x] rename SenderBuilder::new() to SenderBuilder::new_tcp() and introduce a sibling SenderBuilder::new_http() ctor.
• [x] rename remaining parameters in the API to match config string.
• [x] change -> Result<Self> for all params to allow immediate validation failure.
• [x] test params can't override any set in config.
• [x] test tls can't be switched off for tcps and https
• [x] consider if the tcp-only net_interface should be part of the doc - ensure it can't be used for HTTP (I've got an open request with the ureq crate).
• [x] add Sender::from_conf and Sender::from_env constructors.
• [x] perform full validation logic in SenderBuilder::connect.
• [x] consider renaming SenderBuilder::connect() to SenderBuilder::build() -- since it would be misleading for HTTP where no connection takes place.
• [x] update the C api tracking the renames and new err_out params.
• [x] update the wrapper C++ api.
• [x] update the stub test python API, i.e. system_test/questdb_line_sender.py.
• [x] cross-code review Java and Rust implementation for any undesired behaviour discrepancies. Eg. consider if grace_timeout and min_throughput are still the valid names.
• [x] add integration tests for from_conf and from_env for both SenderBuilder and Sender APIs.
• [x] review and update C and C++ docs.
• [x] figure out why CI breaks with the latest questdb master code: Possibly HEAD is no longer supported for the / path on HTTP with the latest questdb changes in master.
• [x] default user agent for C and C++.
• [x] write new from_conf example for each of Rust / C / C++ and register them to the manifest file for cloud and docs.