* You can distinguish connection among others with specific `application_name`
```sql
SELECT application_name FROM pg_stat_activity;
/*
application_name
------------------------
psql
ActionCable-PID-42
(2 rows)
*/
```
* It's possible to customize connection identification with `id` option in `cable.yml`
`ActionCable-PID-#{$$}` is the default value
* Related tests refactoring
* `ActionCable::Server#config.cable` is no mutated anymore inside Redis subscription adapter
Before this commit, the database connection used in Action Cable's
PostgreSQL adapter was "owned" by `ActiveRecord::Base.connection_pool`.
This meant that if, for example, `#clear_reloadable_connections!` was called on the pool, Active
Record would "steal" the database connection from Action Cable, and
would cause all sorts of issues. This became evident during file
reloads; despite Action Cable trying its hardest to return its borrowed
database connection to Active Record via `@pubsub.shutdown`, Active Record calls
`#clear_reloadable_connections!` on the connection pool, and due to the order of callbacks, Active
Record's callback was being executed first. This meant that if you tried
to rerender a view after a file was reloaded, you would have to wait
through Active Record's timeout and such.
Now, Action Cable takes direct ownership of the database connection it
uses. It removes the connection from the pool to avoid the situation
described above. Action Cable also makes sure to call `#disconnect!` on
the connection when appropriate, to match the previous behavior of
Active Record.
[ Jon Moss & Matthew Draper]
`skip` raises an exception to abort the execution of the test, so
`super` would never be called and thus `@rx_adapter` and `@tx_adapter`
would never have been defined at the time of teardown.
Define them just before skipping and zap the warnings.