SETTING MAX_ROWS=0 IS NOT THE SAME AS NEVER SETTING MAX_ROWS

An inplace ALTER TABLE .. MAX_ROWS query intentionally updates only the
mysqld metadata and not the NDB dictionary. And the REORGANIZE
PARTITION query first checks the NDB dictionaries max_rows value to
decide whether to reorganize or not. Due to this outdated value in the
NDB dictionary, REORGANIZE is denied even if the max_rows is set back
to 0.

Also, if the table doesn't have any user defined partition balance, the
default one is used. And when such a table's max_row is changed through
a copy ALTER, its partition balance changes to SPECIFIC. When the
MAX_ROWS is changed back to 0 using a inplace ALTER, in addition to the
MAX_ROWS not being reset in NDB dictionary, the Partition Balance is
not reset to default. Any subsequent ALTER TABLE .. REORGANIZE query
fails as the Partition Balance of the table is still SPECIFIC. But if
the MAX_ROWS is set to 0 using a copy ALTER, the Partition Balance is
reset back to the default and any subsequent online REORGANIZE runs
without any issues.

This patch fixes the above issues by adding checks to deny any attempt
to reset MAX_ROWS to 0 online. Resetting MAX_ROWS to 0 can only be done
through a copy ALTER now. Also, the max_row values provided by MySQL is
now used instead of the NDB dictionary value to make any decisions.