Remove hardcoded refs from ociartifact code

[inknos]

Fixes: https://issues.redhat.com/browse/RUN-3578
Depends on: containers/container-libs#411

Does this PR introduce a user-facing change?

None

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: inknos
Once this PR has been reviewed and has the lgtm label, please assign lsm5 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[inknos]

@baude @Luap99 I am confused on how to write tests for this PR and how to build in this PR when code from container-libs/common is needed

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[Luap99]

you need a go mod replace to build and test temporarily here in podman

https://github.com/containers/container-libs/blob/main/CONTRIBUTING_GO.md#testing-changes-in-a-dependent-repository

I am not sure we need to add a test

[baude]

im ok with no new tests for now.

[TomSweeneyRedHat]

Changes LGTM with a quick breeze

[inknos]

@Luap99 tbh I got lost a little bit thinking how we could append the podman version as a tag. Ideally, that is only when endpoint is the same as config.Machine.Image. I think my implementation is far from being nice, but I am getting closer to the solution.

[Luap99]

Ideally, that is only when endpoint is the same as config.Machine.Image

I don't think is is important and likely not what we want in case RHEL overrides that with a custom image. I think the logic could be quite simple, if it doesn't specify a tag/digest then append the current version. That seems the most logical and consitent behavior for users and documentation purposes because the cli and config values still behave the same then.