roachtest: skip revision history in OR recovery test

[kev-cao]

The OR recovery roachtest would fail if revision history backups were
taken, as the link phase would ingest the SSTs instead of linking them.
Since #170148 moved deleting the SSTs to before the link phase, the link
phase would then fail due to being unable to find the SSTs. This patch
updates the test to avoid taking revision history backups.

Fixes: #170617

Release note: None

Co-Authored-By: roachdev-claude roachdev-claude-bot@cockroachlabs.com

[trunk-io]

😎 Merged successfully - details.

[cockroach-teamcity]

This change is 

[msbutler]

@kev-cao i think the commit message could be clearer here. Is this the story?

• currently, the OR recovery roachtest deletes SSTs before the link phase
• online restore of revision history backups necessarily have to read rev history backups ssts during the link phase, so this test fails before the download phase begins.

I know there was some discussion around why the rev history backups were even read, as they should have been compacted away. is there a tracking issue?

Uber nit here: In general, when referring to other issues in a PR message or issue write up, i think it is helpful to directly link to the precise comment that explains what is going on, instead of to the top level failure that has a bunch investigate output.

[kev-cao]

@msbutler Yeah that's the correct story.

I know there was some discussion around why the rev history backups were even read, as they should have been compacted away. is there a tracking issue?

Maybe this is getting mixed with something else — even with compactions, we still will ingest instead of link the SSTs. In OR, we begin ingesting the moment we see a revision history backup, so if the full is a revision history backup (which it is when using our driver), we ingest all of the SSTs:

cockroach/pkg/backup/restore_span_covering.go

Lines 307 to 316 in 67034ac

	// Find the first layer with revision history. Once we hit a layer with
	// revision history, that layer and all subsequent layers must be ingested
	// (not linked) to maintain correct MVCC/LSM ordering.
	firstRevHistoryLayer := len(backups) // default: no revision history layers
	for i, b := range backups {
	if !b.RevisionStartTime.IsEmpty() || b.MVCCFilter == backuppb.MVCCFilter_All {
	firstRevHistoryLayer = i
	break
	}
	}

---

That being said, I had some discussions with David, and I realized that the reason why we were seeing failures was likely not because Pebble was compacting away SSTs before the download phase could reach it. That wouldn't explain why the tests were failing so much more frequently recently.

It was because we enabled revision history for OR, which meant that 50% of the time, the tests were guaranteed to fail because the link phase would ingest the SSTs instead of linking them.

I'm thinking we merge this PR (skipping revision history is still needed), and then revert the change of only allowing database/table restores).

[kev-cao]

TFTR!

/trunk merge

[blathers-crl]

Detected infrastructure failure on trunk-merge branch (matched: self-hosted runner lost communication with the server). Automatically resubmitting to merge queue (attempt 1 of 2). (run link)

[blathers-crl]

/trunk merge