fix: Set nullable types in operation classes/interfaces

[campersau]

Some parameters can be null like

ContainersPruneParameters parameters = null

so the parameters should be marked as nullable

ContainersPruneParameters? parameters = null

Also replaced default(CancellationToken) with default for consistency.

Changes only affect *Operations interfaces / classes.

[HofmeisterAn]

Thanks for the PR. I have two quick questions.

Some operation interfaces still use ... CancellationToken cancellationToken);. Probably something we should align too?

[campersau]

Some operation interfaces still use ... CancellationToken cancellationToken);. Probably something we should align too?

I have fixed them. There were just 3 in the interfaces and two of them are actually obsolete.

[campersau]

Also some interfaces are implemented explicitly and others are not. If you want I can also make them consistent (either way).

[HofmeisterAn]

Also some interfaces are implemented explicitly and others are not. If you want I can also make them consistent (either way).

If we change it, it would be great to align and make it consistent (as long as it's not too much work). I don't think there's a need to implement them explicitly?

[campersau]

If we change it, it would be great to align and make it consistent (as long as it's not too much work). I don't think there's a need to implement them explicitly?

All Operations interfaces are now implemented implicitly.
I also updated the code to be more consistent.

[HofmeisterAn]

Thanks for all the effort. I slightly polished the changes and made them more consistent. If you're okay with the updates, I'm happy to merge the PR. Thanks again!

[HofmeisterAn]

Thanks 🙏.

You've contributed a lot recently, so I wanted to give you a quick update on what I'm planning to work on next for Docker.DotNet. My goal is to refactor the API (operation interfaces) to support multiple Docker Engine APIs to support the API downgrade feature, along with ongoing cleanups.

I'm not entirely sure how to approach this yet. For now, I'm thinking of introducing a new API alongside the existing one and transitioning to the new API over time. This also include better auto-generated model classes and interfaces (specgen) to streamline development (probably without netstandard support).