bug is actually a weirdness in test system, so moving test portion into maria_notembedded.test

mysql-test/suite/maria/r/maria.result:
  result update
mysql-test/suite/maria/r/maria_notembedded.result:
  result update
mysql-test/suite/maria/t/maria.test:
      Removing test portion into maria_notembedded.test. Explanation below.
      Running maria.test with --mem --embedded --valgrind I got:
      ==378== Invalid read of size 4
      ==378==    at 0x857C755: _lf_pinbox_real_free (lf_alloc-pin.c:342)
      ==378==    by 0x857C640: _lf_pinbox_free (lf_alloc-pin.c:267)
      ==378==    by 0x857D50C: ldelete (lf_hash.c:226)
      ==378==    by 0x857DBC1: lf_hash_delete (lf_hash.c:429)
      ==378==    by 0x8243D82: unlock_lock_and_free_resource
      (waiting_threads.c:676)
      ==378==    by 0x8244A79: wt_thd_release (waiting_threads.c:948)
      ==378==    by 0x83F301D: wt_thd_release_self (trnman.c:98)
      ==378==    by 0x83F3D49: trnman_end_trn (trnman.c:431)
      ==378==    by 0x837C437: ma_commit (ma_commit.c:60)
      ==378==    by 0x835F082: ha_maria::external_lock(THD*, int)
      (ha_maria.cc:2387)
      ==378==    by 0x84D1011: handler::ha_external_lock(THD*, int)
      (handler.cc:4433)
      ==378==    by 0x856DA92: unlock_external(THD*, st_table**, unsigned)
      (lock.cc:786)
      ==378==    by 0x856DD6F: mysql_unlock_tables(THD*, st_mysql_lock*)
      (lock.cc:389)
      ==378==    by 0x8274A57: close_thread_tables(THD*) (sql_base.cc:1307)
      ==378==    by 0x82ABEC3: unlock_locked_tables(THD*) (sql_parse.cc:99)
      ==378==    by 0x82B0BB3: mysql_execute_command(THD*)
      (sql_parse.cc:3372)
      ==378==  Address 0x5894a0c is 164 bytes inside a block of size 184
      free'd
      ==378==    at 0x40233FC: free (vg_replace_malloc.c:323)
      ==378==    by 0x823CF92: my_thread_end (my_thr_init.c:348)
      ==378==    by 0x8200FEE: mysql_thread_end (libmysql.c:250)
      ==378==    by 0x81A9487: send_one_query (mysqltest.c:535)
      ==378==    by 0x4050111: start_thread (in /lib/libpthread-2.5.so)
      ==378==    by 0x41A52ED: clone (in /lib/libc-2.5.so)
      
      (among other errors). The line where the invalid read happens is:
        if (available_stack_size(&pinbox, *pins->stack_ends_here) >
      alloca_size)
      and stack_ends_here was previously set here:
        el->stack_ends_here= & my_thread_var->stack_ends_here;
      The mysqltest "send" command, in embedded mode, is implemented this way
      (mysqltest.c:do_send_query()): a *new OS thread* is created in
      mysqltest, and does this:
      
        mysql_thread_init();
        VOID(mysql_send_query(&cn->mysql, cn->cur_query,
      cn->cur_query_len));
        mysql_thread_end();
      
      So, con_d "send insert t1 values (2)" creates a new OS thread, which
      gets a thread-specific data (mysql_thread_init()), then sends the
      query; in particular, this sets el->stack_ends_here to a pointer inside
      the thread-specific data (see my_thread_var above), that is, thd->pins
      depends on the thread-specific data.
      This sent "insert" blocks as expected, thread-specific data is free()d
      (my_thread_end() above), OS thread terminates.
      Then "default" connection runs "insert t1 values (3)"
      which blocks on the 3 already inserted by the con_d.
      This blocking (see waiting_threads.c) creates a WT_RESOURCE, which has,
      as owner, con_d's WT_THD.
      When con_d calls "unlock tables" (see stack trace), it wants to release
      this resource, which involves con_d's thd->pins, so it ends up reading
      stack_ends_here which points inside the freed thread-specific data =>
      Valgrind error, crashes...
      So this is an effect of having one single connection (con_d) for which
      two queries:
      send insert t1 values (2)
      unlock tables
      are done by different OS threads. That is indeed weird design of
      mysqltest, and it breaks on the dependency of lf_alloc-pin.c on
      thread-specific data. It is maybe already explained in those comments
      in lf_alloc-pin.c:
      "  It is assumed that pins belong to a THD and are not transferable
        between THD's (LF_PINS::stack_ends_here being a primary reason
        for this limitation)."
      "    It is assumed that pins belong to a thread and are not
      transferable
          between threads."
      
      In correct usage of libmysqld (no two queries sent for one connection
      by two threads), this problem would not happen, so I call it a
      deficiency of the test system.
mysql-test/suite/maria/t/maria_notembedded.test:
  moving test portion into maria_notembedded.test

Manually applying the patch for BUG40954 "Crash in MyISAM index code with concurrency test using partitioned tables"
so that it stops crashing pushbuild2/5.1-maria and we can see the other failures which it hid.

mysql-test/r/partition.result:
  Manually applying the patch for BUG40954 "Crash in MyISAM index code with concurrency test using partitioned tables"
mysql-test/t/partition.test:
  Manually applying the patch for BUG40954 "Crash in MyISAM index code with concurrency test using partitioned tables"
sql/ha_partition.cc:
  Manually applying the patch for BUG40954 "Crash in MyISAM index code with concurrency test using partitioned tables"

so cause timeouts. Probably normal as ALTER TABLE does many syncs in Maria, but have to mark them "big"
for pushbuild2.

mysql-test/suite/parts/t/partition_alter2_1_maria.test:
  test takes 15 minutes with Maria (ALTER TABLE does many syncs in Maria)
mysql-test/suite/parts/t/partition_alter2_2_maria.test:
  test takes 15 minutes with Maria (ALTER TABLE does many syncs in Maria)

(i.e. file's size % 8192 != 0). Don't assert on this, Recovery is supposed to fix it.

Under Windows one can get \ instead of / in file names in error messages (fix for pushbuild warning)

mysql-test/lib/mtr_report.pl:
  Under Windows one can get \ instead of / in file names in error messages

      Scenario of the BUG#40731 ("Maria: hang (probably in page cache) under concurrency"):
      T1: Disable logging for the table
      T1: Start inserting into the table
      T2: Tries to lock the table so waits.
      T2: Tries unlock and relock during the process see that the table has disabled logging and reenables it
      T1: Got DBUG_ASSERT because suddenly start use table with transaction switched on which is not expected during bulk insert

storage/maria/ma_pagecache.c:
  Page type print added for debugging purposes.
storage/maria/ma_recovery.c:
  Check that it was this thred which switched off logging (transactional mode).
storage/maria/maria_def.h:
  Flag for controling which thread switched off transactiona mode for the table added.

Merge of 5.1-main into 5.1-maria. There were no changes to storage/myisam, or mysql-test/t/*myisam*.
However there were three new tests mysql-test/suite/parts/t/partition*myisam.test, of which I make here
copies for Maria.

storage/maria/trnman.c:
  During Maria's checkpoint, we walk the list of active transactions; in this list we may find a transaction with a short_id of 0 which means "uninitialized" (is being created right now) and want to ignore this transaction. Such short_id is set under trn->state_lock, so use this mutex to reliably read short_id during checkpoint.

storage/maria/ma_pagecache.c:
  Added correct reaction on find operation status during writing the page.

storage/maria/ma_pagecache.c:
  Added correct reaction on find operation status during writing the page.

            
Innodb monitor could cause a server crash because of invalid access to a
shared variable in a concurrent environment.
                  
This patch adds a guard to protect against crashes but not against
inconsistent values because of performance reasons.

sql/sql_class.cc:
  * Attempt snapshot of static memory pointer proc_info to avoid null pointers.

where it was forgotten to remove them.

refining the regression test to avoid explicit innodb engine in create.

Prevent this by modifying CFLAGS and CXXFLAGS.

Upmerge from 5.0, modified according to the different spec file structure.

support-files/mysql.spec.sh:
  Bug #40546  Debug server in RPM is built with compiler optimization
  
  Modify CFLAGS and CXXFLAGS for the duration of the debug server build
  (implemented by doing it in a subshell)
  so that they do not contain any optimization flag.
  Play it safe and prepare for both gcc and icc.

Prevent this by modifying CFLAGS and CXXFLAGS.

support-files/mysql.spec.sh:
  Bug #40546  Debug server in RPM is built with compiler optimization
  
  Modify CFLAGS and CXXFLAGS for the duration of the debug server build
  (implemented by doing it in a subshell)
  so that they do not contain any optimization flag.
  Play it safe and prepare for both gcc and icc.

Problem 1: BUG#36625: rpl_redirect doesn't do anything useful. It tests an
obsolete feature that was never fully implemented.
Fix 1: Remove rpl_redirect.
Problem 2: rpl_innodb_bug28430 and rpl_flushlog_loop are disabled despite the
bugs for which they were disabled have been fixed.
Fix 2: Re-enable rpl_innodb_bug28430 and rpl_flushlog_loop.


mysql-test/suite/rpl/r/rpl_redirect.result:
  Removed result file for obsolete test.\
mysql-test/suite/rpl/t/disabled.def:
  Re-enabled tests.
mysql-test/suite/rpl/t/rpl_redirect.test:
  Removed obsolete test.

storage/maria/trnman.c:
  Store min used trid in a global variable and change trnman_get_min_trid() to return this variable without using a mutex.
  This is safe as trnman_get_min_trid() is used for trid optimization and all algoritms will work even if it returns a slightly older trid.
  
  Also ensure that LOCK_trn_list is unlocked in trnman_new_trn() in the very unlikely case that lf_hash_get_pins() fails