Remove the ToOCI functions from the specs-go package

[elezar]

This change removes the ToOCI functions from the specs-go package.
They are implemented as private toOCI functions in the cdi package instead.
This means that there is no dependency on the OCI runtime spec for clients that
only need a CDI spec definition.

NOTE: This is a breaking change in that the ToOCI functions no longer exist in the specs-go module, but the impact of this should be minimal and is worth the removal of the require github.com/opencontainers/runtime-spec dependency from the spec definitions.

[elezar]

/cc @pohly

[elezar]

@klihub @marquiz since moving these functions here is a breaking change, do we want to add "empty" implementations to specs-go so that we can mark these as deprecated. Something like:

// ToOCI returns the opencontainers runtime Spec Hook for this Hook.
// 
// Deprecated: Use cdi.Hook.ToOCI instead.
func (h *Hook) ToOCI() interface{} {

}

[bart0sh]

Would it make sense to keep these APIs in the specs-go and add deprecation warnings to them, so both old and new APIs would co-exist for a deprecation period?

[elezar]

The issue with that is that it would not remove the dependency, but yes, we could do that. Would you have a recommendation as to what the deprecation period should be?

[klihub]

I guess if we really deprecate this the right way, we don't get rid of the dependency yet (so we don't return an interface either as suggested). The other alternative would be to do it the 'incorrectly/agressively', and because of the suggested empty interface-return signature change I am not sure if that is what @bart0sh was after, to keep a dummy implementation that is marked as deprecated, and maybe even panic from it.

[bart0sh]

+1 for doing it aggressively. It makes sense after the above explanation, thanks @klihub

[elezar]

@klihub @bart0sh as a general question, I was wondering whether we should actually REMOVE the ToOCI functions here instead (in practice we would make them private). My motivation is that these functions do not make sense in isolation and are only consumed from the Apply functions which actually update the spec.

If we do have clients that use these directly, we can consider how to better add these APIs.

functions made private

[klihub]

@klihub @bart0sh as a general question, I was wondering whether we should actually REMOVE the ToOCI functions here instead (in practice we would make them private). My motivation is that these functions do not make sense in isolation and are only consumed from the Apply functions which actually update the spec.

If we do have clients that use these directly, we can consider how to better add these APIs.

@elezar Good point. If with this change we don't have cross-package use any more then I think making them private makes sense, since/if we don't consider them useful for external users

[elezar]

@klihub I have updated the latest revision with private functions. PTAL.

[klihub]

LGTM

[bart0sh]

LGTM