RENAME/DROP crashes with innodb_track_changed_pages

The redo log reading code has been chaned in 5.5.30 with

  http://bazaar.launchpad.net/~mysql/mysql-server/5.5/revision/2661.834.1

Part of the change is that on MLOG_FILE_RENAME events the
recv_parse_or_apply_log_rec_body() does not only parse but
also applys the rename operation.

This can lead to InnoDB assertion failures if:

* innodb_track_changed_pages is enabled and parses the redo log
* a table is renamed
* and is dropped shortly after

The assertion messages are:

  InnoDB: Error: cannot find space id ### in the tablespace memory cache
  InnoDB: though the table '(name not specified)' in a rename operation should have that id
  InnoDB: Assertion failure in thread ### in file fil0fil.c line 2248

The related backtrace looks like this:

  ??:0(my_print_stacktrace)[0xa83a3e]
  ??:0(handle_fatal_signal)[0x6cc93b]
  ??:0(??)[0x3e9f00f500]
  ??:0(??)[0x3e9ec328a5]
  ??:0(??)[0x3e9ec34085]
  ??:0(fil_op_log_parse_or_replay)[0x8f7e37]
  ??:0(recv_parse_or_apply_log_rec_body)[0x92b936]
  ??:0(recv_parse_log_rec)[0x92be73]
  ??:0(log_online_follow_redo_log)[0x9334ab]
  ??:0(srv_redo_log_follow_thread)[0x86ecad]
  ??:0(??)[0x3e9f007851]
  ??:0(??)[0x3e9ece890d]

The important part of the InnoDB change is:

+ case MLOG_FILE_RENAME:
+ ptr = fil_op_log_parse_or_replay(ptr, end_ptr, type,
+ space_id, 0);
+ break;
        case MLOG_FILE_CREATE:
- case MLOG_FILE_RENAME:
        case MLOG_FILE_DELETE:
        case MLOG_FILE_CREATE2:
                ptr = fil_op_log_parse_or_replay(ptr, end_ptr, type, 0, 0);

which causes MLOG_FILE_RENAME events to be replayed when
the page change cache parses the logs. Now what can happen is
that a table gets renamed and then dropped shortly afterwards.
As the page change tracking thread reads the redo log with a
slight delay it may only end up reaching the RENAME event at
about the time when the DROP happens.

Now if this happens at just the "right" time then
fil_op_log_parse_or_replay() will execute
fil_tablespace_exists_in_mem(id) while the table still
exists, then check for fil_get_space_id_for_table(new_name)
right after it has been dropped, and comes to the wrong
conclusion that the rename has not happened yet and
needs to be recovered/redone. Then next it tries
fil_rename_tablespace() which fails as the space id for the
table no longer exists and eventually the

   cannot find space id ### in the tablespace memory cache

assertion is raised.

So actually a bug introduced by Oracle, but I'm reporting it
here only for now as it only affects the Percona page change
feature but has probably no negative effect on upstream
MySQL itself as the log parsing code is only used for crash
recovery or ibbackup postprocessing and never has to deal
with other DB activity going on in parallel ...