DISPLACEMENT

A supplied temporal string literal could bypass the normal
bounds check for a TIMESTAMP column. This is because the
implementations of Time_zone::TIME_to_gmt_sec() do a
simplified adjustment of the time zone displacement, merely
getting the epoch seconds value and subtracting the
displacement. However, sec_since_epoch() has an ineffective
bounds check in place, which means that you will either hit
an assertion (if you are right on the boundary) or bypass it
altogether (if you are way above the boundary). This was
easily rectified by making sure to call
adjust_time_zone_displacement() as early as possible for
string literals that are resolved as temporal values. This
gets rid of the time zone displacement and hence normal
bounds checks are in place.

However, a standard compliant timestamp literal lying right
on the boundary still triggers an assertion. This time
around it's because adjust_time_zone_displacement() relies
on sec_since_epoch() to do the adjustment calculation. We
obviously need a more robust version, and therefore a new
function sec_since_epoch64() is added, which accepts
everything that str_to_datetime can parse.

With all this in place, what remains is a boundary case when
inserting a value that is just within the DATETIME boundary,
but after adjustment falls outside. There is an assertion in
MYSQL_TIME_cache that enforces that the value is within the
DATETIME boundary. We fix this problem by enabling
adjust_time_zone_displacement() to raise an error in this
case. We do this unconditionally, ignoring sql_mode.

Change-Id: I06a796f30880753d6fdf47607f3fb9234d50b6db