Related trac ticket https://core.trac.wordpress.org/ticket/57824
Reverts WordPress/wordpress-develop#3441
Backport PR WordPress/wordpress-develop#4145

What

This PR fixes a bug by which the reset function of the global styles sidebar wouldn't work as expected in the site editor.

How to reproduce

Take the following steps:

• Using TwentyTwentyTwo and any WordPress version after rev54517, for example, WordPress 6.2 beta 3.
• Go to the site editor.
• Open the global styles sidebar and set the padding values to something else (222px, for example).
• Save the changes and reload the editor.
• Open the global styles sidebar and try resetting the padding values (for example, by using the "Reset to defaults" option displayed under the three dot menu of the global styles sidebar).
• The expected result is that the values would be reset. However, they are not.

Note that if this is saved and then site editor reloaded, the proper data is shown.

How this PR fixes the issue

By reverting WordPress/wordpress-develop#3441 which was the one that introduced the issue.

That PR changed the get_merged_data code to (pseudo-code):

function get_merged_data( $origin ) {
    $result = static::get_core_data();

    if ( 'block' === $origin ) { $result->merge( static::get_block_data() ); }
    if ( 'theme' === $origin ) { $result->merge( static::get_theme_data() ); }
    if ( 'custom' === $origin ) { $result->merge( static::get_custom_data() ); }

    return $result;
}

However, by doing so, the base object ($result) is modifying the $core object directly, and $core ends up storing the consolidated values instead of only the ones coming from the theme.json provided by core.

This is problematic because $core data is cached. Take, for example, the following scenario:

$data = get_merged_data( 'custom' );
$data = get_merged_data( 'theme' );

The expected output for $data is that it should not have data coming from the 'custom' origin, however, it does.

The fix is reverting the change and use an empty object as base (pseudo-code):

function get_merged_data( $origin ) {
    $result = new WP_Theme_JSON();

    $result->merge( static::get_core_data() );
    if ( 'block' === $origin ) { $result->merge( static::get_block_data() ); }
    if ( 'theme' === $origin ) { $result->merge( static::get_theme_data() ); }
    if ( 'custom' === $origin ) { $result->merge( static::get_custom_data() ); }

    return $result;
}

Performance

(The performance data is taken from core, not Gutenberg. Left here as a section for visibility).

This is a bug that needs to be fixed. I thought about running some performance analysis anyway, given the intent of the PR this reverts was improving performance. Given the improvements introduced in 6.2, reverting the PR doesn't affect performance.

Using XDebug (only for completeness, we should not use data extracted from a xdebug profiler to make perf decisions, as there's a cost to observability):

Using production code (see raw data): the variance is sub-millisecond, so it may be attributed to the measuring conditions.