Optimize memory usage of unpacking FBC from pod logs

[joelanford]

In these lines, we copy the logs to a byte buffer, and then turn around and create a reader from the byte buffer.

We may be able to avoid the buffer entirely by feeding the podLog stream directly into declcfg.LoadReader.

Acceptance Criteria:

• Updated memory profile with comparison of relevant sections (controller manager metrics) to ensure there were gains: https://github.com/operator-framework/catalogd/blob/main/pprof/README.md#controller-manager-metrics
• Make use of walk functionality implemented in this PR: Add WalkMetas* functions and meta.Name field operator-registry#1089

[everettraven]

FWIW I attempted to resolve this with 7abf80b#diff-025e5ad2e9e8e55336b0ed5c705b28593c6e6fa342ca89c0ace5e784cd708b2bL298-R394 and the result was that not all objects from the FBC were read before returning. This may indicate that we need to make a change in operator-registry to ensure that when loading from a reader we are reading until we have read everything

[everettraven]

@joelanford I don't think this is an issue anymore due to the change to using the Unpacker interface and implementation that was done in #65 - are we okay to close this now?

[joelanford]

It seems like we still have a similar problem in the unpacker implementation for images:

catalogd/internal/source/image.go

Lines 249 to 253 in a8f7196

	defer logReader.Close()
	buf := &bytes.Buffer{}
	if _, err := io.Copy(buf, logReader); err != nil {
	return nil, err
	}

However, I think the solution is to replace the pod-based image unpacker with a registry client implementation. Shall we go ahead and embark on that path? I created #143 to describe the idea.

[anik120]

This should be superseded by #143 right?

[joelanford]

Yeah, #143 lists this issue (and some others) as issues that will be closed out or obsolete when we implement an image registry client. I'll add "fixes" comments for all of those issues in #145