jdbc: Support Connection.getClientInfo() and setClientInfo() methods

[Totktonada]

It is required by the JDBC standard.

Also need to support DatabaseMetaData.getClientInfoProperties() list of supported properties.

[nicktorwald]

Docs suggest next standard properties to be supported:

• ApplicationName - The name of the application currently utilizing the connection
• ClientUser - The name of the user that the application using the connection is performing work for. This may not be the same as the user name that was used in establishing the connection.
• ClientHostname - The hostname of the computer the application using the connection is running on.

Does Tarantool have any replicated system table where we can keep session data?
Does it make sense to maintain this kinda table on the driver side?
Or maybe DB has built-in command like SET <prop> = <value>, I don't sure.

Anyway, to follow the spec now, we can just say - there're no supported client properties yet.
@Totktonada any comments on this?

[Totktonada]

@nicktorwald Why session local storage is needed to support properties you listed above?

• ApplicationName seems to be entirely driver-side thing.
• A user may call box.session.su('username') within a Lua function. But we cannot receive an information about session variables w/o call / eval. I filed Expose effective user of a current session via iproto tarantool#4226 , but let's don't consider this issue as blocked on that. We can use a user we connected with and this will be okay for most cases I think.
• ClientHostname is IP of a client as a server see it? Or something entirely driver-side? How this is used? For logging?

I would implement those propoerties that can be implemented in more or less correct way driver-side and stop on that for now.

[nicktorwald]

Why session local storage is needed to support properties you listed above?

The session storage is not necessary. It can be any other way to keep the properties in the database.
API says: The driver stores the value specified in a suitable location in the database. For example in a special register, session parameter, or system table column.

ApplicationName seems to be entirely driver-side thing.

See API sentence above regarding the storage places. I'm not sure about in-memory (or driver-side) case.

ClientHostname is IP of a client as a server see it? Or something entirely driver-side? How this is used? For logging?

API says: The values supplied to these methods are used for accounting, diagnostics and debugging purposes only.

I would implement those propoerties that can be implemented in more or less correct way driver-side and stop on that for now.

API: Drivers are not required to support these properties...
The current implementation is almost enough to be compatible. (getClientInfo must return null instead of an exception). So, zero supported properties are alright. I think it's enough for MVP.

FYI: postgres supports only ApplicationName and mssql supports no properties at all.

[Totktonada]

I'm agree. It seems it is better to leave empty properties set for now and wait if there will be real need in this feature.