Fix storage_engine test results

MDEV-9739 Assertion `m_status == DA_ERROR || m_status == DA_OK' failed in Diagnostics_area::message() ; connect.xml* tests fail in buildbot

remove ~15 years old print_lock_error() function, use
handler::print_error() instead

Backport from 10.1

        Test fixed for IA64.

        Calculation of the polygon's centroid fixed.

Following merge from 5.6.36, this merge also rejects changes that
collided with the rejection of 6ca4f693c1ce472e2b1bf7392607c2d1124b4293.

We initially rejected 6ca4f693c1ce472e2b1bf7392607c2d1124b4293 because
it was introducing a new storage engine API method.

One query was removed due to inconsistent behaviour with subquery cache
enabled vs disabled. MDEV-13399 has been created to track this change
and fix.

slave_skip_counter must not be reset to 0 during purge_relay_logs. See
MDEV-4937 as to when this change happened.

Problem was that dict_sys->size tries to maintain used memory
occupied by the data dictionary table and index objects.
However at least on table objects table->heap size can increase
between when table object is inserted to dict_sys and when
it is removed from dict_sys causing inconsistency on amount
of memory added to and removed from dict_sys->size variable.

Removed unnecessary dict_sys:size variable as it is really
used only for status output.

Introduced dict_sys_get_size function to calculate memory
occupied by the data dictionary table and index objects
that is then used on show engine innodb output.

dict_table_add_to_cache(),
dict_table_rename_in_cache(),
dict_table_remove_from_cache_low(),
dict_index_remove_from_cache_low(),
	Remove size calculation.

srv_printf_innodb_monitor(): Use dict_sys_get_size function to
get dictionary memory allocated.

xtradb_internal_hash_tables_fill_table(): Use dict_sys_get_size
function to get dictionary memory allocated.

apparently it uses a smaller per-thread stack

Backport of 7e29f2d6 from 10.1.

Create_field does not set BINARY_FLAG, so the check didn't work at all.
Also, character sets were already compared, so this check would've been
redundant (if it would've worked).

InnoDB fix will come in MDEV-13360.
Here I just fix upgrades from old unfixed InnoDBs - bad data
makes the following copying ALTER TABLE to fail.

MDEV-13173 An RLIKE that previously worked on 10.0 now returns "Got error 'pcre_exec: recursion limit of 100 exceeded' from regexp"

1. use Regexp_processor_pcre::set_recursion_limit() to set the
   recursion limit depending on the current available stack size
2. make pcre stack frame to be estimated no less than 500 bytes.
   sometimes pcre estimates it too low, even though the manual
   says 500+16 bytes (it was estimated only 188 for me, actual
   frame size was 512).
3. do it for embedded too

Change the semantics of thd_get_error_context_description().
It no longer expects the caller to lock LOCK_thread_count
(no caller ever did that anyway), but takes care of it internally.

Problem
rpl.rpl_mdev-11092 fails in buildbot because after starting slave in
wait_for_slave_sql_error_and_skip.inc slave is started but there may be
chances that we have not skipped the last error and Last_SQL_Errno is
still not zero untill the end of rpl_end.inc , which will compare
Last_SQL_Errno to 0. So in this this case rpl_mdev-11092 fails.

Solution
After starting slave in wait_for_slave_sql_error_and_skip.inc we will wait for
Last_SQL_Errno to become 0.

Inspired by: https://github.com/devexp-db/mariadb/blob/f27/mariadb-covscan-stroverflow.patch

Signed-off-by: Daniel Black <daniel.black@au.ibm.com>

test case

simplify.
add a test case.