BTree: no longer search arrays twice to check Ord

[ssomers]

A possible addition to / partial replacement of #83147: no longer linearly search the upper bound of a range in the initial portion of the keys we already know are below the lower bound.

• Should be faster: fewer key comparisons at the cost of some instructions dealing with offsets
• Makes code a little more complicated.
• No longer detects ill-defined Ord implementations, but that wasn't a publicised feature, and was quite incomplete, and was only done in the range and range_mut methods.
  r? @Mark-Simulacrum

[ssomers]

Comparing performance (with various versions of this) always seems to confirm that avoiding the superfluous comparisons pays off in range_included_included, but to my amazement sets back range_included_excluded. No other changes above noise.

 btree::map::range_included_excluded            465,055         490,340               25,285   5.44%   x 0.95
 btree::map::range_included_included            476,255         433,940              -42,315  -8.88%   x 1.10
 btree::map::range_included_unbounded           150,614         149,596               -1,018  -0.68%   x 1.01
 btree::map::range_unbounded_unbounded          76,012          76,010                    -2  -0.00%   x 1.00
 btree::map::range_unbounded_vs_iter            81,179          81,175                    -4  -0.00%   x 1.00

[Mark-Simulacrum]

@bors r+ rollup=never

Seems reasonable.

[bors]

📌 Commit fd6e4e4 has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit fd6e4e4 with merge 88e7862...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 88e7862 to master...