WebSocket always defers the decision to the server, because it didn't
have to deal with legacy compatibility... but the same-origin policy is
still a reasonable default.
Origin checks do not protect against a directly connecting attacker --
they can lie about their host, but can also lie about their origin.
Origin checks protect against a connection from 3rd-party controlled
script in a context where a victim browser's cookies will be passed
along. And if an attacker has breached that protection, they've already
compromised the HTTP session, so treating the WebSocket connection in
the same way seems reasonable.
In case this logic proves incorrect (or anyone just wants to be more
paranoid), we retain a config option to disable it.
* Introduce a connection coder responsible for encoding Cable messages
as WebSocket messages, defaulting to `ActiveSupport::JSON` and duck-
typing to any object responding to `#encode` and `#decode`.
* Consolidate encoding responsibility to the connection. No longer
explicitly JSON-encode from channels or other sources. Pass Cable
messages as Hashes to `#transmit` and rely on it to encode.
* Introduce stream encoders responsible for decoding pubsub messages.
Preserve the currently raw encoding, but make it easy to use JSON.
Same duck type as the connection encoder.
* Revert recent data normalization/quoting (#23649) which treated
`identifier` and `data` values as nested JSON objects rather than as
opaque JSON-encoded strings. That dealt us an awkward hand where we'd
decode JSON strings… or not, but always encode as JSON. Embedding
JSON object values directly is preferably, no extra JSON encoding,
but that should be a purposeful protocol version change rather than
ambiguously, inadvertently supporting multiple message formats.
During the `5.0.0.beta1` release, the CHANGELOGs got an entry like the
following:
```
* No changes.
```
It is kinda confusing as there are indeed changes after it. Not a
biggie, just a small pass over the CHANGELOGs.
[ci skip]
