WL#1796: NdbPool in handler

Currently the handler uses one Ndb object per connection.
This works well for active connections and where the number of connections
are not so high.
If the number of connections are high and/or the activity on a connection is
low then it is preferrable if only a few Ndb objects are reused.

An implementation of a pool of Ndb objects is already at place. This WL is
about using it in the handler. It should be a very small task of getting an
object from the pool before startTransaction and returning it after 
closeTransaction.


The NdbPool defines at creation how many Ndb objects to create immediately
and how many Ndb objects to create maximum.

The NdbPool will always return the same Ndb object to the connection if it is
available. The connection thread needs to save an identity of the Ndb object to
handle this. In the situation where the number of connections are lower than the
maximum number of Ndb objects the NdbPool will thus behave as currently.

When the desired Ndb object is not around it will try to find a free Ndb object
using the same database to reuse as much as possible the local hash table of 
table entries.

When no such Ndb objects exists it will take any free Ndb object and if no free
Ndb object exists and the maximum have already been created then it will wait
until a free Ndb object is returned.

A benchmark and test program was executed using flex_bench_mysql.
The result was that the pool overhead was 1-2% when the number of Ndb objects
was as much as the number of threads. When the number of threads was bigger than
the number of Ndb objects an overhead of 20-30% was seen mostly due to the extra
wait and restart thread activity.

Another test will also be performed where each thread is less active. In the used
test program the threads are extremely active.

It is a preferred implementation that the handler is configurable. The config file
should state
1) Is pooling to be used
2) If pooling is to be used what is the max size of the pool.

It could be interesting to use the pool for two reasons.
1) To be able to save on memory space for systems with large amount of 
connections.
2) Most likely better cache memory behaviour for systems with low activity on
connections.