IGNITE-17424 Basic C++ client

[isapego]

Done:

• Implemented basic C++ client. Current functionality: Start client async, get table by name;
• C++17 was chosen as a target C++ standard. May be changed to C++14 in future, need to discuss it with other C++ guys;
• Using Conan as a package manager;
• Using GTest for tests;
• Compiles on both Windows and Linux;
• Added simple DEVNOTES.md with instructions;
• Code style is not yet established and does not match that of a schema lib. To be done in another ticket once we decide on a common code style.

[ptupitsyn]

General note on async APIs

Currently, the APIs are based on std::future, which is very limited, unfortunately:

• Not possible to get a completion callback.
• Not possible to co_await.

Basically, we can only perform a blocking wait or some kind of busy loop wait.

I think a callback-based API is a better alternative (user can pass a callback that will be invoked upon completion).

• Can be used directly without any libraries or newer language features and achieve non-blocking behavior.
• Can we converted to other async constructs, like std::future, boost::future, awaitable (for co_await in C++ 20).

Example: Asio library with callbacks, futures, coroutines (awaitables)

[ademakov]

Suggested change

	auto pool = m_pool;
	if (pool)
	pool->stop();
	if (auto pool = m_pool)
	pool->stop();

[isapego]

Come on, this is not an error :)

[ademakov]

yes, just a suggestion, you may ignore it

[ademakov]

Any reaction if the connection not found? Perhaps write something to log at least?

[isapego]

This is a normal situation actually. Connection could be closed before we handle a received message.

[ademakov]

Ok. Perhaps write a comment?

[ademakov]

This makes 2 locks on every message. This is not going to scale well. Especially, if I got it correct, considering that after the handshake is done, for all of the following messages these locks are practically useless.

[isapego]

You are right. I'll try to fix it.

[ademakov]

Are we going to have more methods here? And more fields? Currently this class looks excessive. We can move this method (and any methods like this that use only m_connection) directly to ClusterConnection.

[isapego]

Sure. This is an entry point for table management API. There are going to be such methods as createTable, updateTable, dropTable, etc. Currently there are very few methods in user API overall but thats just to not inflate PR which is big enough already.

[ademakov]

LGTM