`_delete_option_fresh_site()` continually queries the database

[dlh]

_delete_option_fresh_site() passes the integer 0 to update_option(), but 0 will later be fetched from the database as the string '0'.

Each time _delete_option_fresh_site() is called, then, when update_option() checks whether the new value is the same as the current value, it will see the two values as different and attempt to perform the database update.

The attached patch would instead pass the string '0' to update_option().

This makes sense to me. It's ironic that for the abundance of loose type checking == equality in WordPress, an instance where strict === equality does exist here in update_option() and it causes a slight performance problem when the publish_post, publish_page, wp_ajax_save-widget, wp_ajax_widgets-order, or customize_save_after actions are done.

@dlh I was trying to add a unit test for this in 41039.1.diff​ but in doing so, I couldn't actually reproduce the issue when your patch was applied or not.

@westonruter I think the second assertion passes when the patch isn't applied because the integer 0 is still cached after do_action( 'customize_save_after' ) was called for the first assertion.

When update_option() runs as part of the second do_action( 'customize_save_after' ), get_option() retrieves the cached integer, and the === test in update_option() passes.

41039.2.diff​ updates the test to regenerate the alloptions cache between assertions, which causes the second assertion to fail without the change to _delete_option_fresh_site().

In 41244:

Customize: Prevent _delete_option_fresh_site() from hitting DB if fresh_site flag already cleared.

Amends [38991].
Props dlh, westonruter.
Fixes #41039.