HDDS-16253. Fix getPipelines() in Recon always returning an empty pipeline list

[shuan1026]

What changes were proposed in this pull request?

ReconContainerMetadataManagerImpl#getPipelines(ContainerKeyPrefix) builds a nested Stream pipeline to collect the Pipelines for a key's block locations, but both .stream().map(...) calls are intermediate operations with no terminal operation attached. Because Java streams are lazily evaluated, the pipelines.add(...) is never actually executed, so the method unconditionally returns the empty ArrayList created at the top of the method.

This method is the only implementation backing ContainerMetadataIterator#next(), which is used by ReconContainerMetadataManager#getContainersIterator(). That iterator feeds two REST endpoints in ContainerEndpoint: GET /containers/mismatch and GET /containers/mismatch/deleted. Both currently return "pipelines": [] for every container, even when the container's key actually has valid pipeline data in OM.

This PR replaces the two dangling .stream().map(...) chains with .forEach(...)

What is the link to the Apache JIRA

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

How was this patch tested?

• Ran the existing TestReconContainerMetadataManagerImpl: 15/15 tests pass.

[chihsuan]

Thanks for wokring on this! @shuan1026

One thing I wanted to check with you. I tried the patch on a local compose cluster, and as soon as there was a single key in it, GET /containers/mismatch?missingIn=SCM started returning a 500. Reverting just these three lines makes it a 200 again.

It looks like the pipeline isn't actually stored alongside the key, so the list ends up filled with nulls rather than pipelines. If that's right, the empty list was hiding the fact that this information can't come from the key at all, and it would need to come from SCM instead, or the field would need to go. Does that match what you're seeing?