fix issue 887

[cenkore]

context: #887

Add a ghost table _xx_gho lock to avoid ghost table blocked after original table lock released.
Coordinating execution sequence with channel: lock original&magic table (session1) -> lock ghost table (session3) -> rename table (session4 #blocked) -> drop magic table (session1) -> unlock ghost table (session3) -> unlock original&magic table (session1)

Deduction:

session1	session2	session3	session4	session5
lock tables t write, _t_del write;	-	-	-	-
OK	-	-	-	-
-	insert into t values(null,13);#blocked	-	-	-
-	#blocked	lock table _t_gho write	-	-
-	#blocked	OK	rename table t to _t_del, _t_gho to t;	-
-	#blocked	-	#blocked(acquire _t_del lock)	begin; select * from _t_gho
-	#blocked	-	#blocked(acquire _t_del lock)	#blocked
drop table _t_del	#blocked	-	#blocked(acquire _t_del lock)	#blocked
OK	#blocked	-	#blocked (got _t1_del lock, acquire _t_gho lock)	#blocked
-	#blocked	unlock tables	#blocked(acquire _t_gho lock)	#blocked
-	#blocked	OK	#blocked(got _t1_gho lock, acquire t lock)	#blocked
unlock tables	#blocked	-	#blocked(acquire t lock)	#blocked
OK	#blocked	-	OK(got all locks)	#blocked
-	OK got t lock	-	-	Failed, table renamed

[brightgogo]

Add a session3 lock _gho table introduce a problem:
If sesssion1 broken after drop table _t_del,
then _gho table lock has not been released ,
then session2 can get the lock a table and write into it.

[cenkore]

Add a session3 lock _gho table introduce a problem:
If sesssion1 broken after drop table _t_del,
then _gho table lock has not been released ,
then session2 can get the lock a table and write into it.

Yes, maybe can add session alive checks at cut-over stage as below, there also have a very small gap on s3: between check s1 and unlock tables. But this gap is about a few milliseconds, almost negligible.

s1: check s3 session before drop magic table, (if error, kill rename session, unlock tables, terminate the current cut-over)
s1: drop magic table, send chan okToUnlockGhostTable to s3 （if s3 broken after s1 drop magic table, rename will only wait original table lock release)
s3: check s1 session after recv chan okToUnlockGhostTable, (if error, kill rename session, unlock tables, terminate the current cut-over)
s3: unlock tables, send chan unlockGhostTableDone to s1
s1: unlock tables after recv chan unlockGhostTableDone. (if s1 broken after s3 unlock tables, rename would continue)