db: handle truncation of shared files with no points

[itsbilal]

Previously, if we shared a truncated file with no points,
we would try to seek on a nil point iterator, which has undefined
behaviour. This change addresses it in truncateSharedFiles, to not
use a nil point iterator.

Fixes #3761.

[cockroach-teamcity]

This change is 

[RaduBerinde]

Reviewable status: 0 of 3 files reviewed, all discussions resolved (waiting on @sumeerbhola)

[sumeerbhola]

Reviewed 3 of 3 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @itsbilal)

---

table_cache.go line 490 at r1 (raw file):

	if kinds.Point() && file.HasPointKeys && err == nil {
		iters.point, err = c.newPointIter(ctx, v, file, cr, opts, internalOpts, dbOpts)
	}

I am a bit confused about why this worked before. IIUC, this PR didn't need to change more code to tolerate iters.point being nil, because many callers are using iterSet.Point which returns an emptyIter if point is nil. btw, should the code in scan_internal.go also use iterSet.Point?

If the earlier code was returning an "invalid iterator" (presumably that means it returns an error), why were those callers that user iterSet.Point not ending up with an error?

[itsbilal]

TFTRs! I've simplified this change a little, and removed the table_cache.go change.

Reviewable status: 2 of 3 files reviewed, 1 unresolved discussion (waiting on @sumeerbhola)

---

table_cache.go line 490 at r1 (raw file):

Previously, sumeerbhola wrote…

I am a bit confused about why this worked before. IIUC, this PR didn't need to change more code to tolerate iters.point being nil, because many callers are using iterSet.Point which returns an emptyIter if point is nil. btw, should the code in scan_internal.go also use iterSet.Point?

If the earlier code was returning an "invalid iterator" (presumably that means it returns an error), why were those callers that user iterSet.Point not ending up with an error?

Good point, and this question had me go digging deeper. I found that we did return a nil iterator either way, so this change was unnecessary and I reverted this half of it. However we still need to get truncateSharedFile to not use a nil iterator; previously it was doing just that, and that was leading to undefined behaviour.

[itsbilal]

TFTR!

[sumeerbhola]

Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @itsbilal)

[itsbilal]

On a closer inspection, this is actually a bug in Excise, and might have implications outside of disaggregated storage too. Basically, an excise of a range key makes us lose all point keys in one instance, even point keys outside the excise bounds.

The fix suggested here actually doesn't fix the metamorphic test failure. I'll close this PR and circle back with the proper fix once I've finished investigating.