Admin Performance: Deactivation Dialogue impact on plugins.php

### Impacted plugin

Jetpack

### Steps to Reproduce

Visit `wp-admin/plugins.php`

### A clear and concise description of what you expected to happen.

Get license data from wp.com API after the plugins page has loaded.

### What actually happened

`Jetpack_Redux_State_Helper::get_initial_state` - While preparing the Redux initial state, it does things like talking to the WordPress.com API to find out what kind of licenses the current user has available.

### Other information

When loading plugins.php, my test site spends a good ~300ms, or 30% of the TTFB inside `Jetpack_Redux_State_Helper::get_initial_state` gathering things in case the user triggers the Jetpack Deactivation dialog.


While preparing the Redux initial state, it does things like talking to the WordPress.com API to find out what kind of licenses the current user has available:


If this can be moved out of the initial requests, and instead be pulled by the JavaScript after loading the plugins page, it will make that page substantially faster.

Internal reference: p1HpG7-ere-p2#comment-52144

### Operating System

_No response_

### OS Version

_No response_

### Browser

Chrome/Chromium

### Browser Version(s)

_No response_

Start at wp-admin/plugins.php and Jetpack_Redux_State_Helper::get_initial_state, then trace the license-data requests to the WordPress.com API. Measure the current page-load cost and determine how the deactivation dialogue obtains the same data after the page has loaded. Done means plugins.php no longer performs this work during its initial request while the dialogue still receives the required license data.

Written by the indexing model from the issue text.