Remove feature flag and ship Woo database sync from staging sites

[andregardi]

Proposed Changes

Review it but do not merge this

We are removing the staging-site-sync-woo feature flag and releasing the Woo SQL Sync to all users.

Testing Instructions

The new messaging should be displayed when WooCommerce plugin is active on the site.

Before creating a staging site

The new Preview and troubleshoot changes before updating your production site message should be visible only when WooCommerce is active.

WooCommerce active	WooCommerce deactivated

Toggling Site database (SQL)

If WooCommerce is not active on the site, you should be able to Sync SQL without any warning.
If WooCommerce is active, you should see the new messaging. If user toggle to sync SQL, the Synchronize button should be disabled until the confirmation checkbox is checked.

WooCommerce active	WooCommerce deactivated

Confirmation modal

After clicking on Synchronize button user should see the final confirmation modal.

If WooCommerce is active, you should see the new warning box.
If WooCommerce is not active, the warning box should not be present.

Also test that if the SQL option is not toggled, the new warning box should not be present even if WooCommerce is active.

WooCommerce active	WooCommerce deactivated	WooCommerce active BUT SQL is not toggled

Test syncing

Complete the sync with WooCommerce toggling the SQL option.
It may take some time, but syncing data from staging to production should work.

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-119514

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-119514&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-119514&env=a8c-for-agencies

[matticbot]

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

• blaze-dashboard
• command-palette-wp-admin
• help-center
• notifications
• odyssey-stats
• whats-new
• wpcom-block-editor

To test WordPress.com changes, run install-plugin.sh $pluginSlug update/launch-woo-sync on your sandbox.

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~77 bytes removed 📉 [gzipped])

name          parsed_size           gzip_size
staging-site       -336 B  (-0.0%)      -77 B  (-0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.