Bug#17063675 USE OF UNINITIALIZED PTHREAD_GETSPECIFIC() KEY IN DEBUG BUILDS

Before this fix, code that uses DBUG_ENTER() and related macros,
when executed very early in the server initialization, typically
when using C++ constructors in static code, could end up executing
my_pthread_getspecific() with a non initialized pthread_key.

The behavior in this case is undefined, and can potentially cause a crash.

This fix is a backport from MySQL 5.7,
which uses a THR_KEY_mysys_initialized variable to keep track of 
the initialization state.

With this fix, calling DBUG_ENTER() and related macro is more robust,
and does nothing when the debug component is not available.
Local merge
Raise version number after cloning 5.6.14
Raise version number after cloning 5.5.34
Empty version change upmerge
BUG#16857395 - EXCESSIVE MEMORY USAGE AFTER REPEATED TRIGGER
               EXCEPTION HANDLERS

Follow up patch to fix the valgrind failure.
Additional test fix for Bug#16083211
Merge to mysql-5.6 (backport)
Bug#16346241 - SERVER CRASH IN ITEM_PARAM::QUERY_VAL_STR

Problem:-
Second execution of prepared statement for query with 
parameter in limit clause, causes an assert when using 
connectors (e.g., Connector C).  


Analysis:-
In prepared statement, LIMIT parameters can be
specified using '?' markers. Value for the parameter can
be supplied while executing the prepared statement.

Passing string, float or double values for LIMIT clause
works well from command-line client. That's because, while 
setting the LIMIT parameter value from a user-variable,
the value is converted to integer value.

However, when prepared statement is executed from other
interfaces as J connectors, or C applications etc,
the value for the parameters are sent to the server
with execute command. Each item in command has value and
the data TYPE. So, while setting parameter values
from this log, value is set to all the parameters
with the same data type as passed.
Here, we have the logic to convert the value to change the 
state and item_type if it is part of LIMIT parameter and 
its item_type is not INT.
But when we reset this parameter we save the item_type but change 
state. So on second execution we have old item_type but our state 
has been changed, which make us to use string type variable 
in Item_param::query_str_val(). This cause an assert.

Fix:
Instead of checking the item_type of the parameter, check for 
the state of the parameter. As state value are reset everytime
we execute the statement.
Bug#16346241 - SERVER CRASH IN ITEM_PARAM::QUERY_VAL_STR
	"Merge fix  from mysql-5.5 to mysql-5.6"
BUG#17294150-POTENTIAL CRASH DUE TO BUFFER OVERRUN IN SSL 
             ERROR HANDLING CODE 

BACKGROUND:
There can be a potential crash due to buffer overrun in 
SSL error handling code due to missing comma in
ssl_error_string[] array in viosslfactories.c.

ANALYSIS:
Found by code Inspection.

FIX:
Added the missing comma in SSL error handling code
in ssl_error_string[] array in viosslfactories.c.
BUG#17294150-POTENTIAL CRASH DUE TO BUFFER OVERRUN IN SSL 
             ERROR HANDLING CODE 

BACKGROUND:
There can be a potential crash due to buffer overrun in 
SSL error handling code due to missing comma in
ssl_error_string[] array in viosslfactories.c.

ANALYSIS:
Found by code Inspection.

FIX:
Added the missing comma in SSL error handling code
in ssl_error_string[] array in viosslfactories.c.
BUG#17294150-POTENTIAL CRASH DUE TO BUFFER OVERRUN IN SSL 
             ERROR HANDLING CODE 

BACKGROUND:
There can be a potential crash due to buffer overrun in 
SSL error handling code due to missing comma in
ssl_error_string[] array in viosslfactories.c.

ANALYSIS:
Found by code Inspection.

FIX:
Added the missing comma in SSL error handling code
in ssl_error_string[] array in viosslfactories.c.
Bug#17309863 AUTO RECONNECT DOES NOT WORK WITH 5.6 LIBMYSQLCLIENT
Reverting the initial patch as it is causing failures.
Bug#17050776 : STARTING EMBEDDED SERVER WITH UNKNOWN OPTION CAUSES ASSERTION.

Issue:
 After the code changes done for BUG#17063675, an ASSERT was added in
 -_my_thread_var() to make sure THR_KEY_mysys is initialized. But there
 might be cases when this _my_therad_var() is called multiple times for 
 a thread (as my_thread_end). Therefore it is prone to assert in this situation.

Fix:
 Replaced DEBUG_ASSERT with if check to make sure cases mentioned above are handled.
Bug#17271055 "STATEMENT/COM" EVENT MEANING IS UNCLEAR

Before this fix, a statement received from a client was instrumented as
follows:

When a new packet is detected at the socket level,
a new statement is started, with a temporary name "statement/com"

Then the packet number is read, so the server knows what type of command the
request is.
The statement name is then refined to for example "statement/com/Query".

The query text is read and given to the parser.
After parsing, the exact type of SQL statement is known.
The statement name is then refined to for example "statement/sql/insert",
which is now a final event name.

The problem with this approach, is that instrument names like:
- "statement/com"
- "statement/com/Query"
are used for special purposes, but this is not obvious.

To collect statistics only for INSERT statements for example,
enabling the "statement/sql/insert" instrument is not sufficient,
the "statement/com" and "statement/com/Query" instruments must be enabled as
well.

Also, for instruments such as "statement/com", no statistics are even
aggregated for this type of statement, because no real statement is ever
classified with "statement/com" as a final name.

The same issue exists with statements read from the relay log on a slave.

With this fix,

1)

Every instrument name in performance_schema.setup_instrument
that corresponds to abstract statements have been renamed, for clarity.

"statement/com/" is renamed to "statement/abstract/new_packet"
"statement/com/Query" is renamed to "statement/abstract/Query"
"statement/rpl/relay_log" is renamed to "statement/abstract/relay_log"

2)

Statistics for abstract statements are no longer displayed in
the following tables:
- events_statements_summary_by_thread_by_event_name
- events_statements_summary_by_account_by_event_name
- events_statements_summary_by_user_by_event_name
- events_statements_summary_by_host_by_event_name
- events_statements_summary_global_by_event_name
Fix for Bug#17377159, ignore mysqld_safe.pid file created by mysqld_safe script
Fix for Bug#17377159, ignore mysqld_safe.pid file created by mysqld_safe script
Corrected the PID_FILE_PATT manipulation
Local merge