Remove of null column in JDBC output when script function is present

[galkk]

Issue #, if available: 111

Description of changes:

Fix of JDBC output when there's script function in group by. It is done by additional analysis in schema preparation step to differentiate script and method fields.

After this fix the output

POST _opendistro/_sql?format=jdbc
{
  "query": "SELECT date_format(utc_time, 'YYYY-MM'),  count(*) from kibana_sample_data_logs group by date_format(utc_time, 'YYYY-MM')"
}

returns, as expected

{
  "schema": [
    {
      "name": "date_format_1721549462",
      "type": "text"
    },
    {
      "name": "COUNT(*)",
      "type": "long"
    }
  ],
  "total": 3,
  "datarows": [
    [
      "2018-08",
      7132
    ],
    [
      "2018-09",
      4552
    ],
    [
      "2018-07",
      2321
    ]
  ],
  "size": 3,
  "status": 200
}

Testing:
integration test, manual via Kibana UI

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[dai-chen]

I don't see the use of this new field member. Did I miss it anywhere?

[galkk]

see answer below. It's part of upcoming PR that I've slipped here. I can move it into different PR or leave it as is, because the change will be part of next PR anyway

[dai-chen]

I assume what we want exactly here is de-duplicate. The !selectField.isScriptField check works on the assumption that there is no aggregate function implemented by painless script right? If so, is this true?

[galkk]

It's even worse (because as per Elastic's DSL script aggregations can be for both Bucket and Metric aggregations), but it will require considerable redesign, because the process of transforming of parsed SQL into current domain model loses a lot of information. For example - for query like

select date_format(format), count(*)
from index
group by date_format(format)
order by date_format(format)

there's no easy way to understand that the date_format is actually the same, because at this stage we're operating only with transformed expressions.

Adding of SQLExpr into field information in this PR is related to future attempt to de-duplication that is necessary for order by.

[abbashus]

Looks OK to me, just address @dai-chen's concern.