Fixes Automattic/wp-calypso#36837

Changes proposed in this Pull Request:

Uses the site URL used as the value of the unmapped_url option returned when requesting a site via REST API.

WordPress.com sites stores in the siteurl option the *.wordpress.com domain of a site, but this does not apply for Jetpack sites where that option could be the default value (same mapped domain as the home URL) or a custom URL defined by the user (i.e. subdirectory installs) that is not intended to be used as unmapped URL.

Given that Jetpack sites don't have an unmapped URL (they all have a mapped domain and can be accessed only through that mapped domain), this PR ensures its value fallbacks to the home URL (which is actually the mapped domain).

This was resulting in issues like Automattic/wp-calypso#36837, caused by Calypso building a wrong preview URL due to the unmapped URL pointing to the subdirectory where the WordPress files live.

Quick note to understand the differences between site and home URLs, since it can be very easy to confuse them:

• Site URL: it is where the admin pages are, along with all the other parts of WordPress, such as the folders /wp-content/ and /wp-include. The value of this setting is displayed in the "Settings > General" screen as "WordPress Address (URL)". It is defined by the WP_SITEURL constant and stored in the siteurl site option.
• Home URL: it is the public-facing part of a site. The value of this setting is displayed in the "Settings > General" screen as "Site Address (URL)". It is defined by the WP_HOME constant and stored in the home site option.

Is this a new feature or does it add/remove features to an existing part of Jetpack?

Fix an existing bug in the REST API shared with WP.com

Testing instructions:

• Set up a Jetpack site with WordPress installed in a subdirectory:
  • Method 1: official and long way.
  • Method 2: hacky and quick way. We'll fake the site URL to make WordPress believe it is in a subdirectory. Since it is actually not in a subdirectory, this will result in the admin pages being unusable, but it'll be enough for testing the front-end and the API.
    • Spin up a JN site running this branch.
    • Connect it to your WordPress.com account.
    • Activate the Hello Dolly plugin, and add this to it with the Plugin Editor:

add_filter( 'site_url', function ( $site_url ) { return $site_url . '/wp'; } );

• Apply D34373-code and sandbox public-api.wordpress.com.
• Make a GET request to https://public-api.wordpress.com/rest/v1.1/sites/<YOUR_JETPACK_SITE>?fields=ID,URL,options&options=unmapped_url.
• Verify the unmapped_url option points to the home URL of your site.
• Go to https://wordpress.com/posts/<YOUR_JETPACK_SITE>.
• Preview a post using the contextual menu on the right:

• Make sure the post is previewed successfully and you don't get a 404 error.
• Repeat steps with a Simple site and confirm posts can be previewed too.

Further testing

• Check there are no regressions in other places where the unmapped URL is used, for both Jetpack and Simple sites:
  • Site redirect (Simple sites only). The unmapped URL is used in the "thank you" screen:
  • Customizer. It should load the *.wordpress.com URL in an iframe for Simple sites, and redirect to the WP Admin customizer for Jetpack sites.
  • Preview a site. It should successfully preview a site with no 404 errors.
  • Preview a post with the classic editor. It should successfully preview a post with no 404 errors.
  • Stats spark line (Simple sites only). The image displayed points to wp-includes and it is built using the unmapped URL:
    .

Proposed changelog entry for your changes:

REST API: Use home URL as unmapped URL