Refactor metadata

[isabelizimm]

• Sets package name in each handler, which allows create_meta to live solely in BaseHandler, rather than in each handler. This also removed the need for describe in each handler.
• On pinning, creates vetiver_meta inside the metadata, which is not loaded on VetiverModel creation, fixing the bug where user data is duplicated. On the R side, a list is pinned with metadata, rather than the model being pinned, and loading the metadata.
• Records package versions of required_pkgs on VetiverModel creation
• Adds more tests for metadata

[machow]

One last high-level thought: I just realized you could stash the model inside a dictionary (like R vetiver does). joblib should be able to serialize / deserialize a dictionary where one field is a model. (But also this way of handling the metadata seems totally reasonable!).

[isabelizimm]

One last high-level thought: I just realized you could stash the model inside a dictionary (like R vetiver does). joblib should be able to serialize / deserialize a dictionary where one field is a model. (But also this way of handling the metadata seems totally reasonable!).

This would make sense if I wanted to mimic R and move ptype and required_pkgs into the dictionary as well (effectively removing the need for vetiver_meta inside a pin). Although, I could pin just a dictionary with just the model, nothing else (unclear what value that would add?). Downfalls of this is that you would have to load the entire joblib file to be able to see the ptype and required_pkgs, which might be useful to be able to see without loading this file.

https://github.com/rstudio/vetiver-r/pull/116 is related to this.

[machow]

Thanks -- that's helpful context around why you have done it this way!