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.

sql/sql_prepare.cc

@@ -877,7 +877,7 @@ static bool insert_params_with_log(Prepared_statement *stmt, uchar *null_array,
         if (param->state == Item_param::NO_VALUE)
           DBUG_RETURN(1);
 
-        if (param->limit_clause_param && param->item_type != Item::INT_ITEM)
+        if (param->limit_clause_param && param->state != Item_param::INT_VALUE)
         {
           param->set_int(param->val_int(), MY_INT64_NUM_DECIMAL_DIGITS);
           param->item_type= Item::INT_ITEM;