introduce "sticky session" concept for handling temporary tables

[otan]

Use case

Today, things like temporary tables rely on the same connection to operate. To ensure that today, we need to ensure we start the clickhouse client with max_open_connections: 1 as per the docs, but that means down our application stack we need to keep 2 versions of clickhouse client:

• one for the default connection pool
• one that is a constructor to starting a new clickhouse client with max_open_connections = 1 and a fixed sticky session.

Describe the solution you'd like

This takes inspiration from the database/sql Golang package and how they handle transactions.

Basically, allow the clickhouseClient to hold a "sticky session" which can occupy the same connection pool (i.e. respect the same max_open_connections).

The API could look something like:

const chClient = createClickhouseClient(...)

// All handled in the closure.
await chClient.execStickySession(async (
  // maybe a different type that inherits the same ClickhouseClient types but indicates it is sticky? 
  chClient: ClickhouseClient,
) {
   // automatically uses the same session id for the next 2 commands
   await chClient.command(...);
   await chClient.command(...)
})

// Or explicitly.
const stickySession = await chClient.startStickySession();
try {
  ...
} finally {
   stickySession.close();
}

Describe the alternatives you've considered

We're basically passing 2 different clickhouse clients down the stack now.