Protect: Check for updated trusted header when activating Protect

#### Steps to reproduce the issue

1. On a site that had Protect previously activated and had a custom TRUSTED_HEADER set at the BP API.
2. Deactivate Protect.
3. Have that TRUSTED_HEADER IP address now be blank or a non-IP value (but still exist).
4. Reactivate Protect.
4. See that you can't.

#### What I expected
Be able to activate Protect.

#### What happened instead
During the module activation process, there is a special call to Protect's IP check:
```
// Protect won't work with mis-configured IPs
if ( 'protect' === $module ) {
include_once JETPACK__PLUGIN_DIR . 'modules/protect/shared-functions.php';
if ( ! jetpack_protect_get_ip() ) {
self::state( 'message', 'protect_misconfigured_ip' );
return false;
}
}
```
https://github.com/Automattic/jetpack/blob/7.8/class.jetpack.php/#L3040-L3047

The `jetpack_protect_get_ip` function checks for the saved trusted header value in the db and if it exists and the header exists, it will use that:
https://github.com/Automattic/jetpack/blob/7.8/modules/protect/shared-functions.php#L163

Since this value will never update when Protect is deactivated, this can lead to a stale state and even if HEs change the trusted header on the API, that change won't filter down.

This is a corner case for sure, but likely something we can fix. Maybe break up the functionality to ensure that the option is set, the header exists, and it is a valid IP (and if so use), otherwise revert back to the `REMOTE_ADDR` value. Or check with the API if the value is set and Protect is deactivated, etc.

Originally reported via 2405509-zen by @csonnek

Start in class.jetpack.php around the Protect activation check, then read modules/protect/shared-functions.php around jetpack_protect_get_ip. Reproduce activation with a saved TRUSTED_HEADER whose current value is blank or non-IP, and verify that deactivation followed by reactivation uses the current valid address and succeeds.

Written by the indexing model from the issue text.