Implemented workaround to unblock an object's edit page form after deleting a custom field

[briddo]

Closes: #1582

What's Changed

Any model which inherits from CustomFieldModel will now log a warning instead of raising a ValidationError if there is stale _custom_field_data, therefore unblocking the UI. It was previously raising a ValidationError because the cleanup task hadn't completed. We don't want to the block the UI because the cleanup task (called here) hasn't yet finished.

[glennmatthews]

Were you able to confirm that this is purely a timing/worker-not-running issue? Or do we have an underlying bug of the custom field data not being cleaned up ever?

Also see this comment on the original issue:

When fixing this, please make sure changelog is created for any object having a choice of this Selection cf assigned.

Is it feasible for the worker task to create a changelog entry when it cleans up the custom-field data on the device object?

[briddo]

Were you able to confirm that this is purely a timing/worker-not-running issue? Or do we have an underlying bug of the custom field data not being cleaned up ever?

Also see this comment on the original issue:

When fixing this, please make sure changelog is created for any object having a choice of this Selection cf assigned.

Is it feasible for the worker task to create a changelog entry when it cleans up the custom-field data on the device object?

Taking too long to implement change logging so opening a new issue for now..