subsequent asserts have the wrong meaning.

- Address Monty's review feedback, part 4

- Address Monty's review feedback, part 3

- Address Monty's review feedback, part 1
- Fix buildbot failure 

- Address Monty's review feedback, part 1

The patch that introduced the new enumeration type Match_flag
for the values of match flags in the records put into join buffers
missed the necessary modifications in JOIN_CACHE::set_match_flag_if_none.
This could cause wrong results for outer joins with on expressions
only over outer tables.

A non-incremental join buffer cannot be used for inner tables of nested
outer joins. That's why when join_cache_level is set to 7 it must
be downgraded to level 6 for the inner tables of nested outer joins.
For the same reason with join_cache_level set to 3 no join buffer is
used for the inner tables of outer joins (we could downgrade it to
level 2, but this level does not support ref access).

Made sure that the function that copy a long varchar field from the record
buffer into a key buffer does not copy bytes after the field value.

Miscalculation of the minimum possible buffer size could trigger
an assert in JOIN_CACHE_HASHED::put_record when if join_buffer_size
was set to the values that is less than the length of one record to
stored in the join buffer.
It happened due to the following mistakes:
- underestimation of space needed for a key in the hash table
  (we have to take into account that hash table can have more
  buckets than the expected number of records).
- the value of maximum total length of all records stored in
  the join buffer was not saved in the field max_used_fieldlength
  by the function calc_used_field_length.

BUG#671361: virtual int Mrr_ordered_index_reader::refill_buffer(): Assertion `!know_key_tuple_params
- Make sure we have enough space for both rowids and keys.

The pushdown condition for the sorted table in a query can be complemented
by the conditions from HAVING. This transformation is done in JOIN::exec
pretty late after the original pushdown condition have been saved in the
field pre_idx_push_select_cond for the sorted table. So this field must
be updated after the inclusion of the condition from HAVING.

- Disable identical key handling optimization when
  IndexConditionPushdown is used

- Make mi_open() use less stack space

- Code cleanup
- Always propagate the error code we got from storage engine all the way up

Currently BNLH join uses a simplified implementation of hash function
when hash function is calculated over the whole key buffer, not only
the significant bytes of it. It means that both building keys and
probing keys both must fill insignificant bytes with the same filler.
Usually 0 is used as such a filler.
Yet the code before patch filled insignificant bytes only for probing
keys. 

try to find a match in the join buffer. It makes sense to check for a match
only those records satisfying WHERE/ON conditions that can be pushed to
the scanned table. It allows us to discard early some join candidates.

Such pushdown conditions were built when BNL join algorithm was employed,
but for they were not built when BNLH algorithm was used.
The patch removes this shortcoming. 

When probing into the hash table of a hashed join cache is performed
the key value should not constructed in the buffer used to build keys
in the hash tables. The constant parts of these keys copied only once,
so they should not be ever overwritten. Otherwise wrong results
can be produced by queries that employ hashed join buffers.