TypeError due to too strict typehint on Constraint Validator

Hi ;)

I unfortunately have to report a bug, although it may well come from how we use the module rather than the actual code.
Not sure why we didn't stumbled on it before, although we just recently made an update to latest dev version of the module. From what I gather this is a validation process that came around 1.2, in last month...

So, we have a Custom Entity Type derived from ContentEntityBase.
In that entity type we defined several custom base fields, including one of "workflow type" in the following way (I renamed the workflow type id for confidentiality reasons)

    $fields['workflow'] = BaseFieldDefinition::create('workflow')
      ->setLabel(isset($da_labels['workflow']) ? $da_labels['workflow'] : t('Etat'))
      ->setSetting('workflow_type', 'our_workflow_type')
      ->setDisplayOptions('form', [
        'type' => 'workflow_default',
        'weight' => 30,
      ])

Whenever we try to submit a create/edit form of our custom entity type, we get the following error...

AH01071: Got error 'PHP message: [2020-06-19 15:26:17] php.ERROR: TypeError: Argument 1 passed to Drupal\\workflow\\Plugin\\Validation\\Constraint\\WorkflowFieldConstraintValidator::isValidFieldname() must be an instance of Drupal\\field\\Entity\\FieldStorageConfig, instance of Drupal\\Core\\Field\\BaseFieldDefinition given, called in /var/www/instancetest/web/modules/contrib/workflow/src/Plugin/Validation/Constraint/WorkflowFieldConstraintValidator.php on line 57 in Drupal\\workflow\\Plugin\\Validation\\Constraint\\WorkflowFieldConstraintValidator->isValidFieldname() (line 69 of /var/www/instancetest/web/modules/contrib/workflow/src/Plugin/Validation/Constraint/WorkflowFieldConstraintValidator.php) #0 /var/www/instancetest/web/modules/contrib/workflow/src/Plugin/Validation/Constraint/WorkflowFieldConstraintValidator.php(57): Drupal\\workflow\\Plugin\\Validation\\Constraint\\WorkflowFieldConstraintValidator->isValidFieldname(Object(Drupal\\Core\\Field\\BaseFieldDefinition)) #1 /var/www/instancetest/web/core/lib/Drupal/Core/TypedData/Validat...PHP message: TypeError: Argument 1 passed to Drupal\\workflow\\Plugin\\Validation\\Constraint\\WorkflowFieldConstraintValidator::isValidFieldname() must be an instance of Drupal\\field\\Entity\\FieldStorageConfig, instance of Drupal\\Core\\Field\\BaseFieldDefinition given, called in /var/www/instancetest/web/modules/contrib/workflow/src/Plugin/Validation/Constraint/WorkflowFieldConstraintValidator.php on line 57 in /var/www/instancetest/web/modules/contrib/workflow/src/Plugin/Validation/Constraint/WorkflowFieldConstraintValidator.php on line 69 #0 /var/www/instancetest/web/modules/contrib/workflow/src/Plugin/Validation/Constraint/WorkflowFieldConstraintValidator.php(57): Drupal\\workflow\\Plugin\\Validation\\Constraint\\WorkflowFieldConstraintValidator->isValidFieldname(Object(Drupal\\Core\\Field\\BaseFieldDefinition))\n#1 /var/www/instancetest/web/core/lib/Drupal/Core/TypedData/Validation/RecursiveContextualValidator.php(196): Drupal\\workflow\\Plugin\\Validation\\Constraint\\WorkflowFieldConstraintValidator->validate(Ob...', referer: http://localhost:9999/custom-entity-type/add

I have to confess I don't understand the objective behind that validation, neither do I know when it was introduced.
IMHO though, it should *not* require strictly a FieldStorageConfig because, as the current case demonstrates, it prevents defining "base fields" in custom entity type (and I don't see any reason why we shouldn't have that possibility).

Would instead type-hinting a parameter being an object implementing https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Field!FieldStorag... an acceptable change?
That interface is common to both fields storages "from base" and "from config" if I'm not mistaken so should be a nice compromise.

What do you think?
If you agree to it, would it be possible to push the change ASAP?
It's a real blocker to us so for now we backrolled to 1.1, but it would be nice if we could keep up with the latest evolutions. :)

Thanks in advance.

Regards,

Laurent Lacôte