HDDS-13066. Return a clear bucket-link error when the linked source does not exist

[rajeshkumarchandolu]

What changes were proposed in this pull request?

When a client strictly follows a bucket link (for example ozone sh key list on a link bucket) and the linked source volume or bucket does not exist, Ozone previously often returned VOLUME_NOT_FOUND, which is misleading because the link bucket itself may exist on a valid target volume. This change remaps that failure to a generic bucket-link message so operators see that the problem is a broken link target, not a missing volume on a direct lookup.

The implementation adds a single catch in private OzoneManager.resolveBucketLink: after at least one link hop has been recorded in visited, if resolution fails with VOLUME_NOT_FOUND or BUCKET_NOT_FOUND, OM throws BUCKET_NOT_FOUND with message Cannot follow bucket link: linked source bucket does not exist. Direct lookups (no link hop) and dangling-link create/metadata paths are unchanged. No new ResultCodes or proto Status values are introduced.

Coverage: two unit tests in TestBucketManagerImpl (resolveBucketLink and listKeys), and a new case in links.robot for a link to a non-existent source volume.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-13066

How was this patch tested?

• Unit tests: mvn -pl :ozone-manager test -Dtest=TestBucketManagerImpl#testResolveBucketLinkMissingSourceVolume,TestBucketManagerImpl#testListKeysOnLinkWithMissingSourceVolume -DfailIfNoTests=false -DskipShade -DskipRecon -DskipDocs
• Smoketest: After mvn clean install -DskipTests -Pdist -DskipShade -DskipRecon -DskipDocs, started hadoop-ozone/dist/target/ozone-*-SNAPSHOT/compose/ozone with OZONE_REPLICATION_FACTOR=3 ./run.sh -d, waited for safemode exit, then ../test-single.sh om basic/links.robot — 19 tests, 19 passed (including Link to non-existent source volume).
• fork-action[build]: https://github.com/rajeshkumarchandolu/ozone/actions/runs/37774900282.

[sarvekshayr]

Thanks @rajeshkumarchandolu for working on this. Please find the below inline comments.

[sarvekshayr]

Lets simplify this -

Suggested change

	${missing} = Generate Random String 5 [NUMBERS]
	${missingVol} = Set Variable ${missing}-missing-source
	Execute ozone sh bucket link ${missingVol}/any-bucket ${target}/dangling-missing-vol
	Execute ozone sh bucket link no-such-volume/no-such-bucket ${target}/dangling-missing-vol

[rajeshkumarchandolu]

@sarvekshayr The Jira isn’t about link create failing when the source is missing — dangling links are allowed and create succeeds today. The issue is after the link exists: operations that follow the link (here key list on the target link bucket) could return VOLUME_NOT_FOUND when the source volume never existed, which is misleading.

This test is meant to mirror that: create the link to a non-existent source, then run key list on the link and check the remapped error/message. A hardcoded no-such-volume/no-such-bucket is fine with me if we keep that second step; I used a random volume name mainly to avoid name clashes in the suite. Happy to simplify the first line if you prefer.

[sarvekshayr]

The test flow is correct - create link, key list and assertions.
I only meant replacing the random name setup with no-such-volume/no-such-bucket link so it reads like the existing "Link to non-existent bucket" test.

[sravani-revuri]

Thanks @rajeshkumarchandolu . few minor comments below.