SQL/ODBC: fix some users of toSQLTCHAR() to not assume identical UTF-8/16/32 string lengths

We already fixed the implementation of toSQLTCHAR() in
66767eea46bea0f19f8ae5ad6ebc641d86867701 to not assume that a UTF-8 or
UTF-32-encoded string has the same number of code points as the
equivalent UTF-16 string, but it turns out that users of the function,
as well as other code, also failed to account for this.

This patch fixes callers of toSQLTCHAR() to use

    const auto encoded = toSQLTCHAR(s);
    ~~~ use encoded.data(), encoded.size() ~~~

(except we can't make `encoded` const, because the SQL API isn't
const-correct and takes void* instead of const void*) instead of the
anti-pattern

   ~~~ use toSQLTCHAR(s).data(), s.size() ~~~

As a drive-by:
- Extract Method qt_string_SQLSetConnectAttr()
  - skipping an unneeded .utf16() call (a NUL-terminated string is not
    required for calling toSQLTCHAR())
- de-duplicate some code in exec()
  - and make a comment there slightly more informative
- replace
  - NULL with nullptr
  - size() == 0 with isEmpty()
  - C-style with constructor-style casts

Pick-to: 6.5 6.4 6.2 5.15
Change-Id: I3696381d0a93af8861ce2b7915f212d9e5e9a243
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>

0 files changed, 0 insertions, 0 deletions