Create a helper hook for field validation

[joshuatf]

Blocked by #37007, #37005

Validation in blocks currently works by locking the post. Locks are connected to a specific ID, so many locks can be added to prevent a post from being saved.

https://github.com/WordPress/gutenberg/blob/8a0eedeb85ba019f7179070f63447bb120e60308/docs/reference-guides/data/data-core-editor.md?plain=1#L1112

To make this easier, we should add some helper hooks around the locking for validation use cases. The hook might look something like this:

const useValidation = ( id, validate ) => {
    const { lockPostSaving } = useDispatch( 'core/editor' );

    if ( ! validate( entity ) ) {
        lockPostSaving( id );
    } else {
        unlockPostSaving( id );
    }
}

And then in our block, we could pass in our own validation logic and ID:

const validateTitle = ( product ) => {
    if ( product.title.length < 2 ) {
        return false;
    }

    return true;
}

useValidation( 'product/title', validateTitle );

We should carefully consider the flexibility of this solution and make sure that it works well for our use case. Some things to consider:

• Does passing the entity work for all use cases?
• Does this surface locks in a meaningful way? Is there a chance the editor remains accidentally locked?
• Does this tie in well with error handling and render? Will we need another util for that?

Acceptance criteria

• A validation hook that is reusable across all fields
• Post saving should be locked when invalid
• Should support async validation as well as sync

[joshuatf]

Estimate: 2

[louwie17]

Hmmm I think we should punt this issue and just make use of the lockPostSaving functions for now within each block we create.
Maybe once we have 7-8 fields moved over to blocks we will have a better idea of what is needed for this and if it would be of benefit.
I am mostly scared that as we create this so early on we will drive ourselves into blockers in the future, where this will actually limit us. I would prefer if we use as many of the native Gutenberg functions for now and come back later to synchronize things if we notice trends.

A hook like this may also cause performance issues, if we are exposing the entire entity within the hook. This will mean the hook has to run on every entity update, instead of only when the desired block updates.
I know there will be cases for this like the slug and sku fields that might require validation when the name field changes.

[louwie17]

Re-added to the cycle after discussion during grooming session.