Bug #14417 RBR: Thread-safety and table maps

Description:
Situation
---------

When executing, it is necessary to decide if the current table is
mapped or require new table-map event to be generated.  All table maps
are invalidated at the end of a transaction (or statement, if
autocommit is on), so by keeping a table map version for each table
and the binary log, it is possible to detect if the last table map
event was generated for an earlier transaction.

Problems
--------

**Guilhem [regarding get_table_id()]**: what if tid was !=
table_mapping::NO_TABLE and has just been set to == by another thread,
under mutex? the read-without-mutex here may see the old, !=, and thus
the function will wrongly do nothing?

**Guilhem [regarding update_table_map_version()]**: I have noted in
several places that there is a LOCK_log mutex missing (for example in
the incrementation above).

Question
--------

Is there a problem with the scheme regarding thread-safety?

How to repeat:
Code inspection.

There is a race condition where a Query_log_event can be inserted between a Table_map_log_event and the corresponding Rows_log_event. The reason is that there is no single lock that protects the sequence of generating these two events. This thread-insafety was noted elsewhere, but is added to this bug since it is related to the use of table maps and table map versions.