Range scan in descending order for c <= <col> <= c type of
ranges was ignoring the DESC flag.
However some engines like InnoDB have the primary key parts 
as a suffix for every secondary key.
When such primary key suffix is used for ordering ignoring 
the DESC is not valid.
But we generally would like to do this because it's faster.
            
Fixed by performing only reverse scan if the primary key is used.
Removed some dead code in the process.

mysql-test/r/innodb_mysql.result:
  Bug#37830 : test case
mysql-test/t/innodb_mysql.test:
  Bug#37830 : test case
sql/opt_range.cc:
  Bug#37830 : 
  - preserve and use used_key_parts to
    distinguish when a primary key suffix is used
  - removed some dead code
sql/opt_range.h:
  Bug#37830 : 
  - preserve used_key_parts
  - dead code removed
sql/sql_select.cc:
  Bug#37830 : Do only reverse order traversal
  if the primary key suffix is used.

If the server failed to expired log files during start up it could crash.

sql/log.cc:
  Added predicate to protect againt cases when current_thd might be NULL.

- Revert the fix for bug 33812
- fixed a win32 warning

client/mysql.cc:
  revert the fix for bug 33812
mysql-test/r/mysql.result:
  revert the fix for bug 33812
mysql-test/t/mysql_delimiter.sql:
  revert the fix for bug 33812
mysys/default.c:
  fixed a win32 warning

Problem: missing initialization, if the previous test
fails leaving table t1, client_xml fails as well.
Fix: adding initialization.

Includes fix for Bug #38180, "options are read from ~/my.cnf instead of ~/.my.cnf"

Don't initalize federated if it's disabled by a command line option.

sql/ha_federated.cc:
  Folow-up on Bug#37069: Don't initalize federated if it's disabled 
  by a command line option.

Pull out some of unpack_dirname() into normalize_dirname(); this
new function does not expand "~" to the home directory.  Use this
function in unpack_dirname(), and use it during init_default_directories()
to remove duplicate entries without losing track of which directory
is a user's home dir.

Reverting the previous patch

- In QUICK_INDEX_MERGE_SELECT::read_keys_and_merge: when we got table->sort from Unique,
  tell init_read_record() not to use rr_from_cache() because a) rowids are already sorted
  and b) it might be that the the data is used by filesort(), which will need record rowids
  (which rr_from_cache() cannot provide).
- Fully de-initialize the table->sort read in QUICK_INDEX_MERGE_SELECT::get_next(). This fixes BUG#35477.
(bk trigger: file as fix for BUG#35478).

sql/filesort.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - make find_all_keys() use quick->get_next() instead of init_read_record(r)/r.read_record() calls
  - added dbug printout
sql/mysql_priv.h:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/opt_range.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - In QUICK_INDEX_MERGE_SELECT::read_keys_and_merge: when we got table->sort from Unique,
    tell init_read_record() not to use rr_from_cache() because a) rowids are already sorted
    and b) it might be that the the data is used by filesort(), which will need record rowids
    (which rr_from_cache() cannot provide).
  - Fully de-initialize the table->sort read in QUICK_INDEX_MERGE_SELECT::get_next().
sql/records.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added disable_rr_cache parameter to init_read_record
  - Added comment
sql/sql_acl.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_delete.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_help.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_select.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_table.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_udf.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record
sql/sql_update.cc:
  BUG#35478: sort_union() returns bad data when sort_buffer_size is hit
  - Added parameter to init_read_record

build)

The crash was caused by freeing the internal parser stack during the parser
execution.
This occured only for complex stored procedures, after reallocating the parser
stack using my_yyoverflow(), with the following C call stack:
- MYSQLparse()
- any rule calling sp_head::restore_lex()
- lex_end()
- x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs)

The root cause is the implementation of stored procedures, which breaks the
assumption from 4.1 that there is only one LEX structure per parser call.

The solution is to separate the LEX structure into:
- attributes that represent a statement (the current LEX structure),
- attributes that relate to the syntax parser itself (Yacc_state),
so that parsing multiple statements in stored programs can create multiple
LEX structures while not changing the unique Yacc_state.

Now, Yacc_state and the existing Lex_input_stream are aggregated into
Parser_state, a structure that represent the complete state of the (Lexical +
Syntax) parser.


mysql-test/r/parser_stack.result:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
mysql-test/t/parser_stack.test:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sp.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sp_head.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_class.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_class.h:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_lex.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_lex.h:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_parse.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_prepare.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_trigger.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_view.cc:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)
sql/sql_yacc.yy:
  Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
  build)

offset for time part in UUIDs was 1/1000 of what it
should be. In other words, offset was off.

Also handle the case where we count into the future
when several UUIDs are generated in one "tick", and
then the next call is late enough for us to unwind
some but not all of those borrowed ticks.

Lastly, handle the case where we keep borrowing and
borrowing until the tick-counter overflows by also
changing into a new "numberspace" by creating a new
random suffix.


mysql-test/r/func_misc.result:
  Show that time-part of UUIDs is correct now.
mysql-test/t/func_misc.test:
  Show that time-part of UUIDs is correct now
  by replicating the C-code's resultin SQL.
  Results also decode to expect date-data on
  command-line (external validation).
  
  No test for unwinding of borrowed ticks as
  this a) is a race and b) depends on what timer
  we get.
sql/item_strfunc.cc:
  correct offset for date/time-part of UUID.
  also make sure that when we counted into
  the future earlier (several UUIDs generated
  in same tick), we only give back as many
  "borrowed" ticks as we can without duplicating
  past timestamps. If our tick-counter overflows
  before we can give back, or if the system-clock
  is set back (by user or Daylight Saving Time),
  we create a new random suffix to avoid
  collisions and clear the tick-counter.

   "funcs_2: The tests do not check if optional character
               sets exist."
2. Minor cleanup

enabled)

Before this fix, the lexer and parser would treat the ';' character as a
different token (either ';' or END_OF_INPUT), based on convoluted logic,
which failed in simple cases where a stored procedure is implemented as a
single statement, and used in a multi query.

With this fix:
- the character ';' is always parsed as a ';' token in the lexer,
- parsing multi queries is implemented in the parser, in the 'query:' rules,
- the value of thd->client_capabilities, which is the capabilities
  negotiated between the client and the server during bootstrap,
  is immutable and not arbitrarily modified during parsing (which was the
  root cause of the bug)

On certain kinds of errors (e.g., out of stack), a call to Item_func_
set_user_var::fix_fields() might fail.  Since the return value of this
call was not checked inside User_var_log_event::exec_event(), continuing
execution after this will cause a crash inside Item_func_set_user_var::
update_hash().

The bug is fixed by aborting execution of the event with an error if
fix_fields() fails, since it is not possible to continue execution anyway.


sql/log_event.cc:
  Aborting execution of event if fix_fields() fails since execution
  of update_hash() might cause a crash.

	to use ANSI_QUOTES

Make all have_* tests universally safe by using ANSI quotes.