Possibility to define manual crop effect as required

Problem/Motivation

Currently there is a strong request for changes by a part of the users ImageWidgetCrop on the possibility of defining a system of marking to make the crops required. A first proposal was rejected which aimed to make the "image_crop" element responsible through the configuration of the ImageWidgetCrop widget to make the crop mandatory. The main drawback of this approach is that the entire element will validate without providing any real precision on what "crop types" will be used. A second axis retained following a brainstorming around this functionality aims to make the crop of the zones of crops obligatory at the moment when the effect is applied in the collection of imageStyle consumed by ImageWidgetCrop. It is therefore a question of adding an option to the basis of the effect «Manual crop» and to define if the crop will trigger a crop obligatory to use the manual harvest or not. This approach seems the most flexible, because it allows to be able to use the same crop type on several ImageStyles but to control exactly which ImageStyle will have to make the harvest obligatory to be used. This approach seems much less restrictive than attaching this option to the CropType (entity) base. The other main reason for making crops mandatory within the "Manual crop" effect is the simplicity of implementation and interactions for consumers of CropApi and not simply a feature strongly linked to ImageWidgetCrop.

Proposed resolution

Scenario 1:

A crop is made from a module that implements the CropTypes and reads the entity by retrieving the "isRequired" information from the CropType database. This method would be unified with existing Hard / Soft limits properties. We would need to modify the CropType entity to add the "is_required" field to check the information to retrieve the "CropType" and thus display the constraint information + block the crop process if the constraint n ' is not satisfied.

Scenario 2:

We perform the crop from a module that implements the Crop API. When retrieving "CropTypes" we get the ImageStyle effect associated with this CropType, depending on whether an "isRequired" flag exists within the manual crop effect configuration, and constraint + block the crop process if the constraint is not satisfied.

Solution 2 is the one in the patch because it seems the most flexible and easy to use. It would be tempting to place this information within the CropType entity but this implies that all consumers of this type crop are impacting out with the ImageStyles effects we enjoy a flexibility and a stronger abstraction layer as we can use the same CropType on several ImageStyles this is the same field definition vs field widget settings. This solution seems to me the most appropriate for a simple and compatible use with all CropAPI users.

Remaining tasks

User interface changes

API changes

Data model changes