## Motivation for the change, related issues

There are some code and documentation references that still point to
`localhost:5400` for dev even though the correct address is now
`127.0.0.1:5400`.

## Implementation details

This updates the plaintext references to `127.0.0.1:5400` and also
updates the JSPI origintrial string to reference the correct address. I
tested this update with the `jspi` branch, and the dev server running on
the `jspi` branch loads in Chrome but only after this change.

## Testing Instructions (or ideally a Blueprint)

- CI

## Motivation for the change, related issues

api.WordPress.org/core/version-check now supports preflight requests,
and so we can remove these header deletions that was to resolve CORS
issues

See #933 for where this was added.

## Testing Instructions (or ideally a Blueprint)

The following blueprint should not have a CORS fetch failure in browser
console.


https://playground.wordpress.net/?mode=seamless#{%22preferredVersions%22:{%22php%22:%228.0%22,%22wp%22:%226.5%22},%22phpExtensionBundles%22:[%22kitchen-sink%22],%22features%22:{%22networking%22:true},%22landingPage%22:%22/wp-admin/update-core.php%22,%22steps%22:[{%22step%22:%22login%22,%22username%22:%22admin%22,%22password%22:%22password%22}]}

…-sink extension bundle. (#1504)

Fixes #1494 

In #1048 I introduced a regression of #819, in that `wp_http_supports( [
'ssl' ] )` no longer returned truthful without the kitchen-sink
extension bundle loaded.

This partially reverts #1048 by keeping the filters for Requests, but
reinstating the deprecated WP_HTTP filters.

It's worth noting, that this is not a direct revert, as it forces the
Fetch/Dummy handlers instead of simply adding them as an option. This is
to match the Requests filter behaviour.

To test this, the following blueprint should land you on a plugin
install page without any errors visible:

https://playground.wordpress.net/#{%22phpExtensionBundles%22:[%22light%22],%22features%22:{%22networking%22:true},%22landingPage%22:%22/wp-admin/plugin-install.php%22,%22steps%22:[{%22step%22:%22login%22,%22username%22:%22admin%22,%22password%22:%22password%22}]}
```
{
  "phpExtensionBundles": [
    "light"
  ],
  "features": {
    "networking": true
  },
  "landingPage": "/wp-admin/plugin-install.php",
  "steps": [
    {
      "step": "login",
      "username": "admin",
      "password": "password"
    }
  ]
}
```

…h network access (#1520)

It can be confusing if one attempts to copypaste that line for reloading
the page as the value for `networking` ends up being `yes;`


### After

![image](https://github.com/WordPress/wordpress-playground/assets/746152/65fd2087-5e85-483f-bd1c-164cebe57e91)



### Before

<img width="1003" alt="image"
src="https://github.com/WordPress/wordpress-playground/assets/746152/adf04f97-b7df-4ead-a2e1-52629f9b54fb">


## Motivation for the change, related issues

While showcasing Playground during WCEU, I found myself failing to
install plugins after copy-pasting the proposed URL until I realized I
was copying an unintended semicolon.

## Implementation details

## Testing Instructions (or ideally a Blueprint)

Fixes 

- #1282


## Implementation details
remove the deprecation lines from the schema

…-as-zip