revert "exporter: fix attestation manifest push order" or make it opt-in #7014

After further investigation, the fix implemented in #7012 looks to be incorrect, and working around a non-OCI-compliant registry.

We should revert the patch, or make it opt-in as a temporary workaround until the problem is fixed in the registry

Copying my comment from #7007 (comment)

There's some discussion ongoing; it looks like this order of pushing was actually intentional, and required by the OCI distribution spec; https://github.com/opencontainers/distribution-spec/blob/v1.1.1/spec.md#push

A registry MUST initially accept an otherwise valid manifest with a subject field that references a manifest that does not exist in the repository, allowing clients to push a manifest and referrers to that manifest in either order. A registry MAY reject a manifest uploaded to the manifest endpoint with descriptors in other fields that reference a manifest or blob that does not exist in the registry. When a manifest is rejected for this reason, it MUST result in one or more MANIFEST_BLOB_UNKNOWN errors

For referrers, the order is intentionally reversed #7012 (comment)

The canonical use case was making sure (detached) signatures are pushed before the object they're signing, so that the manifest doesn't ever exist on the registry without a signature.

We need to look at a suitable solution; long-term, GitLab's registry should be fixed, but perhaps short-term, we could have a temporary escape hatch for non-compliant registries (e.g. through an env-var to opt-in to the behavior).