These two methods:
- Item_result_field::create_tmp_field_ex()
- Item_func_user_var::create_tmp_field_ex()
had duplicate code, except that they used a different type handler.
Adding a protected method Item_result_field::create_tmp_field_ex_from_handler()
with a "const Type_handler*" parameter, and reusing it from the
two mentioned methods.

Field::marked_for_read() and Field::marked_for_write_or_computed()
are being called from plugin/type_inet/sql_type_inet.cc ever since
commit 6ea5c2b5
and thus they cannot be declared inline any more.

Conflicts:
	sql/sql_yacc.yy

MDEV-20591 Already solves this issue, Just enable the test case commented
parts

calc_field_event_length should accurately calculate the size of BLOB type
fields, Instead of returning just the bytes taken by length it should return
length bytes + actual length.

- Moving the implementations of class Inet4 and class Inet6 into separate
  files sql_type_inet.h and sql_type_inet.cc, in order to reuse them
  for the INET6 data type and inet function collection.
- Adding a warning in the case when IS_IPV4_MAPPED() and IS_IPV4_COMPAT()
  erroneously gets an IPv4 address instead of the expected IPv6 address.

LEX::parsed_select_expr_cont(): Replace a condition with an
assertion DBUG_ASSERT(!s2->next_select()), and always
initialize sel1=s2, because all subsequent code paths will
assign to sel1->first_nested.

This was flagged by GCC reporting -Wmaybe-uninitialized
for the statement last->link_neighbour(sel1).

Moving geometry types aggregation inside Type_collection_geometry

This change introduces a static method Type_aggregator::find_handler_in_array(),
which will later be reused by other data type plugins.

If we have a mixture of:
- a MariaDB standard (built-in permanent) data type, and
- a non-standard (optionally compiled or pluggable) data type,
then ask the type collection of the non-standard type to aggregate the mixture.

If the non-standard collection fails, then continue aggregation
with Type_handler_data.

Adding error reporting (ER_UNKNOWN_DATA_TYPE) when a handler name read
from EXTRA2_FIELD_DATA_TYPE_INFO is not known to the server.

* MDEV-20225 BF aborting SP execution

When stored procedure execution was chosen as victim for a BF abort, the old implemnetationn called for rollback immediately
when execution was inside SP isntruction. Technically this happened in wsrep_after_statement() call, which identified the
need for a rollback.
The problem was that MariaDB does not accept rollback (nor commit) inside sub statement, there are several asserts about it,
checking for THD::in_sub_stmt.

This patch contains a fix, which skips calling wsrep_after_statement() for SP execution, which is marked as BF must abort. Instead,
we return error code to upper level, where rollback will eventually happen, ouside of SP execution.
Also, appending the affected trigger table (dropped or created) in the populated key set for the write set,
which prevents parallel applying of other transactions working on the same table.

* MDEV-20225 BF aborting SP execution, second patch

First PR missed 4 commits, which are now squashed in this patch:
- Added galera_sp_bf_abort test.
  A MTR test case which will reproduce BF-BF conflict if all keys
  corresponding to affected tables are not assigned for DROP TRIGGER.
- Fixed incorrect use of sync pointsin MDEV-20225
- Added condition for SQLCOM_DROP_TRIGGER in wsrep_can_run_in_toi()
  to make it replicate.

* MDEV-20225 BF aborting SP execution, third patch

The galera_trigger.test caused a situation, where SP invocation caused a trigger
to fire, and the trigger executed as sub statement SP, and was BF aborted by applier.
because of wsrep_after_statement() was called for the sub-statement level, it ended up
in exeuting rollback and asserted there.
Thus fix will catch sub-statement level SP execution, and avoids calling wsrep_after_statement()