MDEV-6657: Poor plan choice for ORDER BY key DESC optimization...

The problem was caused by the following scenario:
- range optimizer picks an index IDX1 which doesn't match the ORDER BY ...
  LIMIT clause.
- test_if_skip_sort_order() decides to switch to index IDX2 which matches
  the ORDER BY ... LIMIT.
- it runs SQL_SELECT::test_quick_select() for the second time to produce
  an quick select for IDX2.
- However, test_quick_select() would figure that full index scan on IDX1
  is still cheaper (its calculations ignore the LIMIT n).

Fixed this by
- passing force_quick_range=true to test_quick_select()
- in test_quick_select, don't consider full index scans if the mentioned
  parameter is true.

Numerous changes in .result files are caused by test_quick_select() being
run after "early/late NULLs filtering" feature has injected NOT NULL
condition.
Merge 10.1 into bb-10.1-mdev6657
MDEV-6402: Optimizer doesn't choose best execution plan when composite...

Fix test_if_skip_sort_order() logic:
WHEN
we use index X, which doesn't produce needed ordering, but there is
an index Y which does and has the same prefix as used prefix of X
THEN
don't just switch to using ref access on Y. If range(Y) would use more
key parts, use range(Y).
Merge ../10.1-mdev6402 into bb-10.1-orderby-fixes
Merge ../10.1-mdev6657 into bb-10.1-orderby-fixes
MDEV-6796: Unable to skip filesort when using implicit extended key

Re-work test_if_order_by_key() to work correctly for extended indexes.
MDEV-6814: Server crashes in calculate_key_len on query with ORDER BY
- if test_if_skip_sort_order() decides to switch to using an index, or
  switch from using ref to using quick select, it should set all
  members accordingly.
Merge ../10.1-orderby-fixes into 10.1