Evalml: Disallow recall as an automl objective

I think precision and accuracy are fine in the sense they won't give you a trivial model.

we don't necessarily want to delete recall as an objective, it just shouldn't optimize against it in automl search. for example, I might want to optimize for f1, but then see my recall score along side of it

@kmax12 yeah, right, we don't want to delete the code which computes recall, and we want to still support computing recall as a score on a pipeline, but we do want to disallow it as a supported optimization objective in automl.

This reminds me of the ongoing discussion around the binary classification plotting/info methods for ROC and confusion matrix (#427, #365). Those aren't metrics we can optimize for in automl, and they're also not single-number scores, but under our API, the easiest way to define them was to add them as instances of ObjectiveBase.

We currently have a number of things which can be computed using pipelines:

1. Predictions
2. Objective function scores for automl
3. Scoring metrics, after automl
4. Plotting data (example for binary classification: ROC curve, confusion matrix)
5. Feature importances

I think to date we've been trying to use ObjectiveBase to represent 2, 3, and 4. In other words, we're missing a clear API to define scoring methods and plotting methods, separate from the automl process.

I think the next step here should be to design those APIs. Looks like I already filed that as #392. I'll update this ticket to be blocked on that.

For the objectives API rework right now, we've moved ROC and Confusion Matrix to PlotMetrics instead (less design went into this, this was the just the easiest way to separate out these two from the rest of the objectives without breaking things). We've also added can_optimize_threshold as an attribute for BinaryClassificationObjective, so if fit() is called with an objective with can_optimize_threshold=True then we optimize for that objective, otherwise we optimize for Accuracy. Thoughts on this and how this might align with some of the questions raised here? Would it be unclear if a user called fit on Recall but instead we optimized for Accuracy instead?

@angela97lin yes, I think moving ROC/confusion out from ObjectiveBase was a positive step! I think #392 should track going further. Let's continue the conversation about how to update the API on #392 instead. That way, this issue can just track updating recall once we've made a decision about how to handle this stuff more generally.

Also I think binary classification threshold optimization is a separate subject, and thankfully one that your ongoing work in #346 is handling 100%!

Summarizing discussion with @eccabay and @jeremyliweishih earlier: Options for supporting this are:

• Delete the recall objectives entirely.
• Delete the entries for the recall objectives in objectives/utils.py OPTIONS, and confirm that disallows those objectives in automl.