Adjust "root of to-be-deleted subtree" function.

Restructure the function that locates the root of the to-be-deleted
subtree during nbtree page deletion.  Handle the conditions that make
page deletion unsafe in a slightly more uniform way, and acknowledge the
fact that the behavior with incomplete splits on internal pages is
different (as pointed out in the nbtree README as of commit 35bc0ec).
Also invent new terminology that avoids ambiguity around which pages are
about to be deleted.  Consistently use the term "to-be-deleted subtree",
not the ambiguous term "branch".

We were calling the subtree parent page the "top parent page", but that
was quite misleading.  The top parent page usually refers to a page
unlinked from its siblings and marked deleted (during the second stage
of page deletion).  There was one kind of top parent page that we merely
removed a downlink from, and another kind of top parent page that we
actually marked deleted.  Eliminate the ambiguity by inventing a new
term ("subtree parent page") that refers to the former kind of page
only.

Author: petergeoghegan

src/backend/access/nbtree/README

@@ -223,9 +223,10 @@ right to make this happen --- a scan moving in the opposite direction
 might miss the items if so.)  Also, we *never* delete the rightmost page
 on a tree level (this restriction simplifies the traversal algorithms, as
 explained below).  Page deletion always begins from an empty leaf page.  An
-internal page can only be deleted as part of a branch leading to a leaf
-page, where each internal page has only one child and that child is also to
-be deleted.
+internal page can only be deleted as part of deleting an entire subtree.
+This is always a "skinny" subtree consisting of a "chain" of internal pages
+plus a single leaf page.  There is one page on each level of the subtree,
+and each level/page covers the same key space.
 
 Deleting a leaf page is a two-stage process.  In the first stage, the page
 is unlinked from its parent, and marked as half-dead.  The parent page must
@@ -243,7 +244,12 @@ it, but it's still linked to its siblings.
 
 (Note: Lanin and Shasha prefer to make the key space move left, but their
 argument for doing so hinges on not having left-links, which we have
-anyway.  So we simplify the algorithm by moving the key space right.)
+anyway.  So we simplify the algorithm by moving the key space right.  This
+is only possible because we don't match on a separator key when ascending
+the tree during a page split, unlike Lehman and Yao/Lanin and Shasha -- it
+doesn't matter if the downlink is re-found in a pivot tuple whose separator
+key does not match the one encountered when inserter initially descended
+the tree.)
 
 To preserve consistency on the parent level, we cannot merge the key space
 of a page into its right sibling unless the right sibling is a child of

src/backend/access/nbtree/nbtinsert.c

@@ -2278,7 +2278,8 @@ _bt_finish_split(Relation rel, Buffer lbuf, BTStack stack)
  *		stack.  For example, the checkingunique _bt_doinsert() case may
  *		have to step right when there are many physical duplicates, and its
  *		scantid forces an insertion to the right of the "first page the
- *		value could be on".
+ *		value could be on".  (This is also relied on by all of our callers
+ *		when dealing with !heapkeyspace indexes.)
  *
  *		Returns write-locked parent page buffer, or InvalidBuffer if pivot
  *		tuple not found (should not happen).  Adjusts bts_blkno &