Consider options for more flexible ptype specification

[juliasilge]

The ptype concept here in vetiver is used as an input data prototype, for checking that the format of new data at prediction conforms to what the model had at training time.

It is already possible to totally turn off this checking, when appropriate to a certain use case.

In discussions with @t-kalinowski he explained to me how it will likely be important for keras, etc to be able to have more flexible, partially defined input data shapes/prototypes such as an array that is fixed in some dimensions but could be any length in another dimension. I don't currently have great ideas for this, something flexible between "no checking" and "very strict checking".

[juliasilge]

We may be able to use vctrs::new_partial() here.

[juliasilge]

I have been working on initial support for keras in #164 and here is where I plan to go initially:

• Error if length(model$inputs) > 1 to exclude multi-input keras models for now. The handling of body in the POST request is going to get pretty complex for multiple inputs, so let's wait to see how folks use it and if they want support for the multi-input model.
• Require folks to either set save_prototype = FALSE for no checking of new data or input some prototype_data (like for ranger), so like vetiver_model(keras_fit, "cars-keras", prototype_data = data.frame(x_train)[1,]). This still is "rectangular data" only. Let's see how important the higher dimensional case (like images or other non-rectangular data) is for folks and understand how they want this to behave.

I am happy to hear 👂 about what the most important use cases for folks are, so we can build out to more complex support of what keras is capable of.