feat(republish): option to preserve original date

[faisalahammad]

Context

• Issue Option to only adjust post_modify date when scheduling blog posts updates #403: when a Rewrite & Republish update is scheduled, the copy's future publish date is written to the original post, so the post jumps to the top of feeds and post lists. Users asked for an option to mimic default WordPress behavior, where only the modified date changes.

Summary

This PR can be summarized in the following changelog entry:

• Adds a setting to keep the original publication date when a scheduled Rewrite & Republish update is applied.

Relevant technical choices:

• The new duplicate_post_preserve_date_on_scheduled_republish option is disabled by default, so existing behavior is unchanged unless users opt in.
• When enabled, republish_post_elements() unsets post_date, post_date_gmt, post_modified and post_modified_gmt on the post object passed to wp_update_post(). Core keeps the original publish date from the database and regenerates the modified timestamps on update.
• The flag is only passed from republish_scheduled_post(), so the immediate Republish flow is not affected.
• An unchecked checkbox is saved as null by the Settings API. The option is read with an (int) cast, so null reads as disabled.

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

• Go to Settings > Duplicate Post, What to copy tab, tick the new "Preserve the original publication date" box under Scheduled Rewrite & Republish and save the settings.
• Publish a post and set its publish date in the past, for example January 1, 2020.
• Open that post with Rewrite & Republish, change the title and content, and schedule the copy for republishing about two minutes in the future.
• Let the WP-cron trigger fire, for example by running wp cron event run --due-now with WP-CLI, or by running the pending future post event with the WP Crontrol plugin.
• Check the original post: title and content are updated, the status is publish, the publish date is still January 1, 2020, the modified date is now, and the copy is gone.
• Untick the option, save, and repeat the same steps on another post. Result: the original adopts the scheduled future publish date, which is the current behavior.
• Also run an immediate (non-scheduled) Republish once to confirm it keeps working as before in both states of the option.
• Automated coverage added: unit tests for both option states, plus WP integration tests asserting the preserved publish date, the refreshed modified date and the unchanged default behavior. Full suites pass (318 unit, 137 integration).

Relevant test scenarios

• Changes should be tested with the browser console open
• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies
• Changes should be tested on different editors (Default Block/Gutenberg/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

QA can test this PR by following these steps:

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

• Only the scheduled Rewrite & Republish flow in Post_Republisher. Cloning, the immediate Republish flow and normal post saving are not touched. The plugin hooks into future_to_publish, so a quick check that scheduling a normal (non Rewrite & Republish) future post still works as usual is advisable.

UI changes

• This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.

Documentation

• I have written documentation for this change. For example, comments in the Relevant technical choices, comments in the code, documentation on Confluence / shared Google Drive / Yoast developer portal, or other.

Quality assurance

• I have tested this code to the best of my abilities
• I have added unittests to verify the code works as intended

Innovation

• No innovation project is applicable for this PR.
• This PR falls under an innovation project. I have attached the innovation label and noted the work hours.

Fixes #403