pgsql: Don't set the truncation block length greater than RELSEG_SIZE.

Don't set the truncation block length greater than RELSEG_SIZE.

When faced with a relation containing more than 1 physical segment
(i.e. >1GB, with normal settings), the previous code could compute a
truncation block length greater than RELSEG_SIZE, which could lead to
restore failures of this form:

file "%s" has truncation block length %u in excess of segment size %u

The fix is simply to clamp the maximum computed truncation_block_length
to RELSEG_SiZE. I have also added some comments to clarify the logic.

The test case was written by Oleg Tkachenko, but I have rewritten its
comments.

Reported-by: Oleg Tkachenko <oatkachenko(at)gmail(dot)com>
Diagnosed-by: Oleg Tkachenko <oatkachenko(at)gmail(dot)com>
Co-authored-by: Robert Haas <rhaas(at)postgresql(dot)org>
Co-authored-by: Oleg Tkachenko <oatkachenko(at)gmail(dot)com>
Reviewed-by: Amul Sul <sulamul(at)gmail(dot)com>
Backpatch-through: 17
Discussion: http://postgr.es/m/00FEFC88-EA1D-4271-B38F-EB741733A84A@gmail.com

Branch
------
REL_18_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/c80b0c9d63b25a1e7fc751a4cf66a6510ffafbb8

Modified Files
--------------
src/backend/backup/basebackup_incremental.c | 14 +++
src/bin/pg_combinebackup/meson.build | 1 +
.../t/011_incremental_backup_truncation_block.pl | 101 +++++++++++++++++++++
3 files changed, 116 insertions(+)