* rename check_if_table_exists() -> table_exists() and remove unneeded arguments

"
  revision-id: sanja@askmonty.org-20110511110948-4kdevwzomvk56y1w
  committer: sanja@askmonty.org
  branch nick: work-maria-5.1-CREATE-merge
  timestamp: Wed 2011-05-11 14:09:48 +0300
    Bugfix: New table creation/renaming block added if old encoded table present
"
the old behavior was less inconsistent than the new one.
In the new one the error message was sometimes different (under LOCK TABLES e.g.),
and there were race conditions (if this CREATE happened when a concurrent ALTER
has renamed the old table away but haven't put the new table in place)

The old one was like "(when using old table names) for DML #mysql50# prefix
is optional, for DDL it's required".

simplify open_table_def()

* print "table doesn't exist in engine" when a table doesn't exist in the engine,
  instead of "file not found" (if no file was involved)
* print a complete filename that cannot be found ('t1.MYI', not 't1')
* it's not an error for a DROP if a table doesn't exist in the engine (or some table
  files cannot be found) - if the DROP succeeded regardless

have a specially defined enum with clearly named values

and now-unused read_string() function

and let open_binary_frm to parse it from the buffer, not a file.
this avoids jumping back in forth in the frm file, and doing
intermediate buffer mallocs.

also:
* move few tests from archive/archive.test to archive/discover.test
* fix (unintentionally) bug#34104, updated result files

after all engines have discovered their tables
  
side effect: correct alphabetical sorting as in ORDER BY ... COLLATE utf8_bin,
information_schema is no longer the first after find_files(),
tables like #mysql50#zzz are sorted first (as per table name),
not last (as per file name zzz).

* make find_files static

there is no "upstream" OQGraph version that needs to stay compatible
with different MariaDB releases.

* provide a default bas_ext value of the empty list

and handlerton::table_exists_in_engine (new implementation is coming),
and handlerton::license (redundant)

when the function has a dedicated flag for this very use case.

(PLUGIN_VAR_MEMALLOC ix 0x8000 and cannot be saved in a char as such)

* replace pointer acrobatics with a struct
* make sorting explicit: MY_DONT_SORT -> MY_WANT_SORT
(if you want something to be done - say it. fixes all places where
my_dir() was used without thinking)
* typo s/number_off_files/number_of_files/
* directory_file_name() doesn't need to be extern
* remove #ifdef __BORLANDC__
* ignore '.' and '..' entries

treated as coming from the overlay.
  
(example: archive suite, test_sql_discovery overlay, mysql-test/include/have_archive.inc)

and sometimes harmful (used with expressions)

mysqltest: At line 477: query 'show explain for $thr2' failed: 1933: Target is not running an EXPLAINable command

After the fix for MDEV-4144, subquery with WHERE pk= (select ...) became a degenerate, constant 
SELECT.  It is not executed in normal way anymore, so it is not possible to catch it in-execution.

  
Analysis:
The reason for the inefficent plan was that Item_subselect::is_expensive()
didn't detect the special case when a subquery was optimized, but had no
join plan because it either has no table, or its tables have been optimized
away, or the optimizer detected that the result set is empty.
  
Solution:
Identify the special cases above in the Item_subselect::is_expensive(),
and consider such degenerate subqueries inexpensive.

This bug was introduced by the patch for WL#3220.
If the memory allocated for the tree to store unique elements
to be counted is not big enough to include all of them then
an external file is used to store the elements.
The unique elements are guaranteed not to be nulls. So, when 
reading them from the file we don't have to care about the null
flags of the read values. However, we should remove the flag 
at the very beginning of the process. If we don't do it and
if the last value written into the record buffer for the field
whose distinct values needs to be counted happens to be null,
then all values read from the file  are considered to be nulls
and are not counted in.
The fix does not remove a possible null flag for the read values.
Rather it just counts the values in the same way it was done
before WL #3220.