add and patch containerd/pkg/shim to be used with new Windows shims

[rawahars]

This PR introduces a vendored and modified version of the upstream containerd/pkg/shim package. This transition will benefit the newer Windows shims, allowing for a more modular and reusable shim management logic. Moreover, By aligning with the upstream pkg/shim structure, we enable better interoperability with containerd v2 while maintaining the specific hooks necessary for Windows.

Key changes

• Added files from https://github.com/containerd/containerd/tree/af7f63f434454efaf8de0fe51c15c54628170786/pkg/shim
• Added Windows specific methods which were missing
• Added logic in serve workflow so that we can signal the calling process that it is ready to serve connections.
• Other logic changes to align with Windows workflow

Testing

Created a new shim and tested it with this logic.

[helsaawy]

theres already containerd/pkg/shim that implements a lot of the management and parsing needed, can we leverage that?

[rawahars]

@helsaawy Using the upstream shim pkg would have been the absolute right way to go. However, Windows implementation is not yet robust upstream. Reference- https://github.com/containerd/containerd/blob/main/pkg/shim/shim_windows.go

Also, we have custom logic related to setting up ETW provider among other things.

In my opinion, as a follow-up to the new shim, we can work to ensure that containerd's shim pkg has robust Windows implementation and then move our new shim to the upstream package once it is released.

What are your thoughts?

[helsaawy]

Even without the Run logic to start and manage a shim server, integrating with it now would allow moving to the BootstrapParams containerd is now expecting (instead of the "address" file)
especially for utilities like ReadRuntimeOptions and the event publisher plugin

[rawahars]

@helsaawy While I totally agree, the upstream shim implementation has stubbed out even newServer method which is used for creating the TTRPC server. Without that we cannot integrate at all.