SQL: client identification harmonisation

[bpintea]

The REST request objects currently contain two client identification-related fields:

• mode which can be explicitly one of: CLI, JDBC, ODBC or PLAIN (=default, if nothing else specified);
• client_id which can be one of CANVAS, CLI, JDBC, ODBC32, ODBC64 or REST (=default, if nothing else specified); as well as a now historical ODBC.

While the two fields came to be with gradual evolution and have technically different purposes - former, for response generation, latter, for telemetry purposes - there is an injective relationship between them and thus a redundancy.

With the advent of version compatibility effort, there is the possibility of simplifying the code processing[2] them and harmonising their usage in the client[1].

The proposal is to simply extract the mode from the client_id, as the simplest change, since all the clients populate that field already.
An alternative to that would be to drop them both and replace the source of information from a (new to add) HTTP header (potentially usable in conjunction with another versioning header).

[1] Usage by client:

• Kibana/Canvas: client_id
• Kibana/Console: none
• JDBC, CLI: mode
• ODBC: both.

[2] Telemetry client identification, currently:

• if mode==ODBC : client_id
• else if mode==PLAIN (i.e. mode absent, in practice) : client_id
• else: "toString"(mode).
  and that resolves either to an enum'ed client_id or defaults to REST, if no match.

[elasticmachine]

Pinging @elastic/es-search (:Search/SQL)

[bpintea]

Proposal dropped for the convenience of possibly later adding more client_ids.