Be more liberal in allowing for index merges

MYSQL_VERSION

@@ -1,5 +1,5 @@
 MYSQL_VERSION_MAJOR=8
 MYSQL_VERSION_MINOR=4
 MYSQL_VERSION_PATCH=5
-MYSQL_VERSION_EXTRA=-5
+MYSQL_VERSION_EXTRA=-501
 MYSQL_VERSION_MATURITY="LTS"

sql/join_optimizer/join_optimizer.cc

@@ -1496,14 +1496,14 @@ bool CostingReceiver::FindIndexRangeScans(
       // case that creates multiple candidates). ANDs in index merges are pretty
       // much always handled nonexactly (see the comment on PossibleIndexMerge),
       // ie., we pick one part of the conjunction and have to check the other
-      // by filter. Verify that the ANDing marked the tree as inexact.
-      assert(merge.inexact || new_tree->merges.size() == 1);
+      // by filter. So we need to note here that this has happened.
+      merge.inexact |= (new_tree->merges.size() > 1);
 
       // Similarly, if there is also range scan arising from this predicate
       // (again because of an AND inside an OR), we need to handle the index
       // merge nonexactly, as the index merge will need to have the range
       // predicate in a filter on top of it.
-      assert(merge.inexact || new_tree->keys_map.is_clear_all());
+      merge.inexact |= !new_tree->keys_map.is_clear_all();
 
       index_merges.push_back(merge);
     }

storage/innobase/include/univ.i

@@ -56,7 +56,7 @@ this program; if not, write to the Free Software Foundation, Inc.,
 #define INNODB_VERSION_BUGFIX MYSQL_VERSION_PATCH
 
 #ifndef PERCONA_INNODB_VERSION
-#define PERCONA_INNODB_VERSION 5
+#define PERCONA_INNODB_VERSION 501
 #endif
 
 /* The following is the InnoDB version as shown in