The problem is that, when the value of a timestamp field is
used as argument to IF() condition in SQL, its
datatype/value changes based on the setting of variable
collation_connection.  More details of this issue is
reported in Bug#27143384. This bug will be fixed independent
of fix for this bug. The root cause of core dump is that the
value of mysql.table_stats.cached_time is treated as a
string value, when collation_connection is set to
utf32_general_ci.  Converting this string version of
timestamp into a integer value gives us a invalid longlong
timestamp value. When we use this wrong timestamp value to
get MYSQL_TIME, we end-up getting invalid date values and
assert.

The expression which hits the issue in Bug#27143384 is,
"IF(ISNULL(timestamp_field), 0, timestamp_field)". This
patch uses COALESCE() which suite better. Part of problem
was the optimizer by default converts the timestamp fields
into strings.  And the IF() resulted in automatic conversion
to integer only in certain charset (as discussed in
bug27143384). In order to avoid depending on implicit
conversions, this patch uses CAST() to explicitly request
the timestamp value as a unsigned value. This code change
can be a permanent change, and need not really be reverted
back after Bug#27143384 is fixed.

The patch also sets null_on_null property for UDF's as
false. The UDF return's NULL as soon as it sees one of it's
argument is NULL. This change is not really required for
the fix in hand. However, this change was expected to be done
for UDF's implemented in I_S as per optimizer's suggestions
in past. The test case contains a SELECT with TABLE_ROWS
column in WHERE condition, which demonstrates the problem.

The patch also sets the few other internal I_S functions
with Functype as DD_INTERNAL_FUNC. This was a omission
when I_S.FILES system view was implemented.

A new test case is added to main.information_schema.

Change-Id: I6904103094c288958af46b6c203a726c31b3093d