Add support for including additional crates

[Anton Whalley]

Currently the base image only includes serde to handle JSON messages and surf for http requests.
It's unclear at the moment if the best way to handle the inclusion of additional crates to the base image is to add the ability to reference other base images or pickup a Cargo.toml from the same directory as the functions.rs.
Allowing multiple base images is probably less work in roche but adds complexity for endusers as they have to understand the baseimage construct.
Using a Cargo.toml could possibly add to the build time significantly which would defeat the purpose of this tool.

[Anton Whalley]

As per zulip conversation with @pepoviola
Workspaces could be an a good way to package multiple baseimages - https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
Also cargo-chef is worth investigating for a more structured approach to the docker layers
https://crates.io/crates/cargo-chef

[Anton Whalley]

Had a look at https://github.com/LukeMathWalker/cargo-chef.
It's a very similar approach to the way we are doing builds already but chef is explicit with it's caching definitions and layering.
It's good validation for the way roche is doing things but not sure we need it right now as we aren't rebuilding the idea is that you won't be rebuilding the base images much if at all during a function development cycle.

It could be useful for managing the building of multiple base images if we need to go to workspaces but not a requirement at the moment.

[Anton Whalley]

Now that we have a couple of templates this might be worth some further consideration.
The story so far is that templates have an images folder that currently stores dockerfiles for dev and release.
A test image is also catered for in roche but currently the test image is just a reference to the dev one.
If a user wants to add a new dep they would have to do the following steps

1. clone a template repo that they want to use as a base.
2. Add the crate to the Cargo.toml in image
3. Add the crate to the Cargo.toml in the top level of the repo
4. Build the images for both dev and release
5. Update the .rocherc to point to a new images
6. Commit the new template to a repo
7. If they also want others to use the template they would have to push the images to a public registry
   Cargo chef may help put structure around those steps but it's not clear if it will actually help short cut any of them.

Another route could be

1. User creates the project from a template
2. Add the dep to the Cargo.toml in their local folder
3. A new command roche merge -t new-baseimage is ran
4. roche merge creates Dockerfiles for each of the dockerfile in images (dev,release) copies in Cargo.toml and reruns them
5. roche merge updates .rocherc in the local project folder to point to the new created image.

It's also worth noting that other FaaS solutions just bundle all the options in and pass it to you as a context object and ignore extensiblity somewhat we could take that approach by having an Uber_State object.
https://github.com/roche-rs/mongodb/blob/main/src/functions.rs#L17