INCORRECT BEHAVIOR

Issue:
------
This problem occurs when a stored procedure contains a
query with a view. While resolving the columns in the
WHERE condition, find_field_in_view insists on creating a
Item_direct_view_ref object every time an execution
happens. This object is not destroyed at the end of the
execution.

In the next execution, a new object is created and will be
appended to the free_list. Hence the size of the free_list
is growing and the cleanup phase at the end of each execute
takes increasingly longer time.

Solution:
---------
This is a regression due to the fix for BUG#19897405.

Ideally the Item_direct_view_ref object (which is related
to the view's column in WHERE clause) should be created at
the beginning of every execution and destroyed at the end.
This doesn't happen because the check related to the status
(STMT_INITIALIZED_FOR_SP / STMT_EXECUTED) had been removed.
This check has been re-introduced.

Scenario 1 in BUG#19897405:
--------------------------
a) SP is executed--> The view fields are resolved/fixed.
b) FLUSH TABLE <table-name>.
c) SP is executed--> Triggers re-prepare--> Query arena
   state is not reset and remains as 'STMT_EXECUTED'.
   Previously created Item_direct_view_ref object is
   destroyed. The view fields are resolved/fixed
   using the execution mem_root. It creates a new
   Item_direct_view_ref object, this is destroyed at the
   end of the execution.
d) SP is executed--> Server crashes while trying to access
   the resolved view columns allocated on the execution
   mem_root which was freed after execution(c).

Solution to Scenario 1 in BUG#19897405:
---------------------------------------
The root cause of the problem mentioned in BUG#19897405 is
that when a re-prepare error is raised due to a
FLUSH TABLE / DROP TABLE, the state of statement arena
should be switched to STMT_INITIALIZED_FOR_SP. Without
this, the statement is unaware that previously created
Item_direct_view_ref have been destroyed after the table
re-open. While it creates a new Item_direct_view_ref
object, this is destroyed at the end of the execution.
Hence the execution that follows will not have any
Item_direct_view_ref to use.

The fix here is to set the state to STMT_INITIALIZED_FOR_SP
after the re-prepare error is raised.


Problem 2 in BUG#19897405:
--------------------------
a) SP is executed--> The view fields are resolved/fixed.
b) SP is executed--> Gets re-prepare error. Destroys
   Item_direct_view_ref object. At the end "TABLE EXISTS"
   error is raised and state is set to EXECUTED
c) DROP TABLE <table-created-in-sp>
d) SP is executed--> Creates new item_direct_view_ref
   object. Destroys the object at the end of the statement.
d) DROP TABLE <table-created-in-sp>
e) SP is executed--> Server crashes while trying to
   access the resolved view columns allocated on the
   execution mem_root which was freed after execution.

Solution to Scenario 2 in BUG#19897405:
---------------------------------------
CREATE TABLE ... SELECT statement in an SP requires some
special handling. The state is always set to
STMT_INITIALIZED_FOR_SP in such a case.