grants are reapplied.


After renaming a user and trying to re-apply grants results in additional
grants.

This is because we use username as part of the key for GRANT_TABLE structure.
When the user is renamed, we only change the username stored and the hash key
still contains the old user name and this results in the extra privileges

Fixed by rebuilding the hash key and updating the column_priv_hash structure
when the user is renamed

mysql-test/r/grant3.result:
  Bug #41597 - After rename of user, there are additional grants when 
               grants are reapplied.
  
  Testcase for BUG#41597
mysql-test/t/grant3.test:
  Bug #41597 - After rename of user, there are additional grants when 
               grants are reapplied.
  
  Testcase for BUG#41597
sql/sql_acl.cc:
  Bug #41597 - After rename of user, there are additional grants when 
               grants are reapplied.
  
  Fixed handle_grant_struct() to update the hash key when the user is renamed.
  Added to set_user_details() method to GRANT_NAME class

There are some problems about help text:
- It is stated that "auto" is the default twice. It need be stated only once.
- It is stated that --base64-output is short for --base64-output=always. But that sounds
like the default is "always", not "auto".

Make the help text clear as following:
Determine when the output statements should be base64-encoded BINLOG 
statements: 'never' disables it and works only for binlogs without 
row-based events; 'auto' prints base64 only when necessary (i.e., 
for row-based events and format description events); 'always' prints 
base64 whenever possible. 'always' is for debugging only and should 
not be used in a production system. If this argument is not given, 
the default is 'auto'; if it is given with no argument, 'always' is used.

Problem: the "caseinfo" member of CHARSET_INFO structure was not
initialized for user-defined Unicode collations, which made the
server crash.
Fix: initializing caseinfo properly.

Adding tests for the bug.

A contributed patch by Andrei Boros (SCA signed).
- Fixing locale definition file
- Adding tests

Problem: using null microsecond part in a WHERE condition 
(e.g. WHERE date_time_field <= "YYYY-MM-DD HH:MM:SS.0000") 
may lead to wrong results due to improper DATETIMEs 
comparison in some cases.

Fix: comparing DATETIMEs as strings we must trim trailing 0's
in such cases.


mysql-test/r/innodb_mysql.result:
  Fix for bug#47963: Wrong results when index is used
    - test result.
mysql-test/t/innodb_mysql.test:
  Fix for bug#47963: Wrong results when index is used
    - test case.
sql/item.cc:
  Fix for bug#47963: Wrong results when index is used
    - comparing DATETIMEs as strings we must trim trailing 0's in the 
  microsecond part to ensure
  'YYYY-MM-DD HH:MM:SS.000' == 'YYYY-MM-DD HH:MM:SS'

 
The problem was in incorrect handling of predicates involving 
NULL as a constant value by the range optimizer. 
 
For example, when creating a SEL_ARG node from a condition of 
the form "field < const" (which would normally result in the 
"NULL < field < const" SEL_ARG),  the special case when "const" 
is NULL was not taken into account, so "NULL < field < NULL" 
was produced for the "field < NULL" condition. 
 
As a result, SEL_ARG structures of this form could not be 
further optimized which in turn could lead to incorrectly 
constructed SEL_ARG trees. In particular, code assuming SEL_ARG 
structures to always form a sequence of ordered disjoint 
intervals could enter an infinite loop under some 
circumstances. 
 
Fixed by changing get_mm_leaf() so that for any sargable 
predicate except "<=>" involving NULL as a constant, "empty" 
SEL_ARG is returned, since such a predicate is always false. 

mysql-test/r/partition_pruning.result:
  Fixed a broken test case.
mysql-test/r/range.result:
  Added a test case for bug #47123.
mysql-test/r/subselect.result:
  Fixed a broken test cases.
mysql-test/t/range.test:
  Added a test case for bug #47123.
sql/opt_range.cc:
  Fixed get_mm_leaf() so that for any sargable
  predicate except "<=>" involving NULL as a constant, "empty"
  SEL_ARG is returned, since such a predicate is always false.

Use "#ifdef", not plain "#if".

            view that has Group By
      
When SELECT'ing from a view that mentions another,
materialized, view, access was being denied. The issue was
resolved by lifting a special case which avoided such access
checking in check_single_table_access. In the past, this was
necessary since if such a check were performed, the error
message would be downgraded to a warning in the case of SHOW
CREATE VIEW. The downgrading of errors was meant to handle
only that scenario, but could not distinguish the two as it
read only the error messages.
      
The special case was needed in the fix of bug no 36086.
Before that, views were confused with derived tables.
      
After bug no 35996 was fixed, the manipulation of errors
during SHOW CREATE VIEW execution is not dependent on the
actual error messages in the queue, it rather looks at the
actual cause of the error and takes appropriate
action. Hence the aforementioned special case is now
superfluous and the bug is fixed.


mysql-test/r/view_grant.result:
  Bug#46019: Test result.
mysql-test/t/view_grant.test:
  Bug#46019: Test case.
sql/sql_parse.cc:
  Bug#46019: fix.

      
Implemented the server infrastructure for the fix:

1. Added a function LEX_STRING *thd_query_string(THD) to return
a LEX_STRING structure instead of char *.
This is the function that must be called in innodb instead of 
thd_query()

2. Did some encapsulation in THD : aggregated thd_query and 
thd_query_length into a LEX_STRING and made accessor and mutator 
methods for easy code updating. 

3. Updated the server code to use the new methods where applicable.

Temporary tables may set join->group to 0 even though there is 
grouping. Also need to test if sum_func_count>0 when JOIN::exec() 
decides whether to present results in a grouped manner.

sql/sql_select.cc:
  Temporary tables may set join->group to 0 even though there is 
  grouping. Also need to test if sum_func_count>0 when JOIN::exec() 
  decides whether to present results in a grouped manner.