WL#3048: partitioning fixes

remove mysql_wait_completed_table function, .par fle and
handler::create_handler_files(). make packfrm to be called out of ha_ndbcluster,
not from generic alter table code. handle_opt_part/print_error bug

mysql_wait_completed_table
^^^^^^^^^^^^^^^^^^^^^^^^^^
it's not necessary, there's no need to wait at the end, only makes sense to wait
before doing something.

.par file and handler::create_handler_files()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sergei:

what is that ? why do you need handler::create_handler_files ?
to write .par file, you will say.

Problems are:

1. it's basically useless for any other storage engine - "handler files"
   (e.g. MRG, MYD, MYI, ARN, etc) are created in handler::create

2. ha_partition uses it incorrectly - in CREATE TABLE, .par file should be
   created in ::create, subject to all the conditions that apply to ::create,
   e.g.  if (!create_info->frm_only), and whatever may be introduced later.

so the method is not for "creating handler files" (as it's the task of
::create), what is it for ? let's see

ha_partition::create also creates underlying partitions, while
create_handler_files() only changes the partition list. So it's for changing
metadata without touching the data, Fine, but

3. create_handler_files() could only help when changing partition
   information, modifying other metadata (indexes, column types)
   cannot be done with create_handler_files().

Thus, it's not even "update_table_metadata" method. It's
"update_partition_metadata_without_doing_real_partition_changes"
I don't think class handler needs such a method.

4. You invented binary format to store partition information in .par file
   but you use sql to store it in frm. Why ?

A better solution:
- keep metadata only in .frm - as csv, archive, federated do.

Mikael: the handler file .par was invented for one and only one purpose.
This is that rename_table and delete_table can be called on tables that
are not opened. Thus the only way to discover the names of the partitions
for this table is to save it in a separate file unless I should do some
strange murky thing by from the handler open the table.
And yes, it is a very specific ha_partition problem that I don't expect
other handlers to have so I could make it a specific ha_partition call
if that would be better.

Monty: in 5.1 there is a function to open only .frm, without opening handler
files. It should be used here instead of .par file.

packfrm
^^^^^^^

no need for a packfrm here. why should MySQL compress the frm before giving it
to the handler ?  the latter may want to parse/analyze it (especially when frm
will be plaintext) if NDB wants to compress is to reduce the traffic and to
store it in machine-independent format, it's details of ndb implementation,
other handlers may not need it. Thus, MySQL should give frm to the handler as
is, and ndb will pack it internally.

handle_opt_part/print_error bug
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

handle_opt_part calls handler::print_error(), passing the return value of
handler admin command. Handler admin commands return HA_ADMIN_xxx codes, while
print_error expects HA_ERR_xxx code.

no_xxx variables
^^^^^^^^^^^^^^^^

rename all no_xxx variables in partitioning code to num_xxx (e.g. no_partitions
to num_partitions) as it confuses everybody who looks at the code.

don't use db_type
^^^^^^^^^^^^^^^^^

Partitioning handler relies on stable db_type values. This is wrong - loadable
storage engine don't provide them. Currently ha_partition stores db_type for
partitions in .frm and in .par. The latter will solve itself when .par will go
away. The former - as full partitioning syntax is stored as plain SQL in .frm
file, it could just as well use ENGINE=xxx that is part of that syntax.