For the engines which support primary key(PK) extension
if total key length exceeds MAX_KEY_LENGTH or number of
key parts exceeds MAX_REF_PARTS, PK key parts which
don't fit within limits are not added to secondary key(SK).
But PK key parts are unconditionally marked as part of
secondary keys. See the following comment in
table.cc:

/*
  If this field is part of the primary key and all keys contains
  the primary key, then we can use any key to find this column
*/

It leads to the situation when SK is treated as a covering key,
and incorrect access method can be chosen.

The fix:
  Function add_pk_parts_to_sk() is modified so that it clears
  PK field part_of_key/part_of_sortkey bits for the PK key parts
  which don't fit within MAX_KEY_LENGTH or MAX_REF_PARTS limits.
  (for 5.7 only)

Reviewed-by: Roy Lyseng <roy.lyseng@oracle.com>
Change-Id: Ie6ed067c67b1075a1fbf0b173dad2233d9a3cafa