Make ContainerOptions Deserializable

[zicklag]

What did you implement:

This implements Deserialize on ContainerOptions. I switched the keys in the ContainerOptions.params hash map to owned strings instead of &'static str. Technically these could be borrowed from the deserialized value, but I think that would be cumbersome to use.

Closes: #216

How did you verify your change:

Not at all yet ( this is work-in-progress ). I'll be testing it soon.

What (if anything) would need to be called out in the CHANGELOG for the next release:

Just a note that Deserialize is now implemented for ContainerOptions.

[zicklag]

OK this is turning into a little bit more than making ContainerOptions serializable. After trying to use the changes in my project I realized that it made more sense for me to make ContainerOptionsBuilder deserializable because I need to be able to create the builder, write the builder to disk, read the builder from disk, and modify the builder whenever I want. There is no good way to modify ContainerOptions so I had to use the builder instead.

Additionally I need to be able to change the container image after the builder has been instantiated, so I created a function for that.

I am also going to need the ability to remove exposed ports, so I will add that to this PR as well if you are OK with that.

Edit: I'm also curious how you feel about being able to get parameters such as the container image as well as set them. This may be too far outside of what you are wanting to go for for this API. If it is, I can make my own "ContainerOptionsBuilderBuilder" type in my project that will facilitate my needs. I think that may be better in this case, unless you want to re-craft the ContainerOptionsBuilder to be a more general purpose config object that can be modified and queried arbitrarily, which would likely be a breaking API change.

If you would like to pursue that option for this, then I will gladly continue working on the PR for it, but otherwise I will just add a type to my own project that I can use.

[softprops]

Thanks for the change

[softprops]

Sorry about the delay on this.

For a long while all of my gh motifs were going to my email spam folder so I likely missed this question before. I think this is a good change that adds some flexibility that doesn’t exist today. This is one of my earlier crates so I was still figuring out what good looked like. If I had more time I’d be doing more refactoring.

I really appreciate pulls like yours

[zicklag]

No problem, glad it's useful. :) I think I was going to need this for a project and then didn't end up needing it.

I've personally written code, and then gone back to it and been like, "oh, I wish I would have known what I know now when I wrote this, it would have been a lot nicer". 🙂

[softprops]

Ok. Let me know if you want to move forward with this. If not let's revisit this when inspiration strikes again :)