Per Chromium team this has not been necessary on other platforms for quite some time: https://bugs.chromium.org/p/chromium/issues/detail?id=737678#c1

Why:

* When getting an error that generates a screenshot it would be helpful
  to be able to ctrl+click it to quickly open it in the browser, which
  does not work with relative paths

This change addresses the need by:

* Changing `image_path` to disregard the relative path and use the
  absolute one instead

Change the system tests to set Puma as default server only when the user haven't specified manually another server.

Not everyone uses iTerm2 and whereas Terminal.app on a mac just ignores
that and outputs the path, other terminals like those on Ubuntu do not.
A friendlier default is one that works by default.

Closes #31159
Closes #30957

Unlike `resize_window`, `resize_window_to` has three arguments.
https://github.com/thoughtbot/capybara-webkit/blob/d63c3c8e3ae844f0c59359532a6dcb50f4a64d0a/lib/capybara/webkit/driver.rb#L135-L143

Therefore, if pass only width and height just like `resize_window`,
`ArgumentError`will be raised.
To prevent this, explicitly pass window handler.

Follow up of #31046

  >[DEPRECATION] Capybara::Webkit::Driver#resize_window is
  deprecated. Please use Capybara::Window#resize_to instead.

See: https://github.com/teamcapybara/capybara/blob/7d693f068c44f6a460336da70fb6e9e5f94f3db9/lib/capybara.rb#L450

In Rails engine `Rails.root `returns the path of the dummy application.
Therefore, there is no `tmp` directly where the test is running, so can
not get the screenshot.
For this reason, instead of directly specifying tmp, retrive screenshot by
relative path from the current directory.

Fixes #30405

Without this, `display_image` raises an error as follwing:

```
RuntimeError: can't modify frozen String
    rails/actionpack/lib/action_dispatch/system_testing/test_helpers/screenshot_helper.rb:72:in `display_image'
    rails/actionpack/test/dispatch/system_testing/screenshot_helper_test.rb:40:in `block (2 levels) in <class:ScreenshotHelperTest>'
```

It's possible for developers toadd a custom driver and then call it
using `driven_by`. Because we were only skipping `register` for
`:rack_test` that meant any custom driver would attempt to be registered
as well.

The three listed here are special because Rails registers them with
special options. If you're registering your own custom driver then you
don't want to separately register that driver.

Fixes #29688

This reverts commit 3420a145, reversing
changes made to afb66a5a.

This is motivated by our usage of system test in RSpec. Puma lazily
boots the first time a system test is used, but this causes some
unfortunate output to appear in the middle of the user's green dots. An
example of this can be seen in @derekprior's comment
[here](https://github.com/rspec/rspec-rails/pull/1813#issuecomment-309252314).

There are alternatives in RSpec where we attempt to intercept the puma
boot and prevent the output from being made there, but that would
involve some monkey patching. This seems like a cleaner solution.

drivers.

When using `driver_by` with capybara-webkit or poltergeist,
SystemTesting::Driver will register the driver while passing
`screen_size` and `options` parameteres.

`options` could contain any option supported by the underlying driver.

`visit "/"` will visit always "http://127.0.0.1" even when we call `host!`:

```ruby
class SomeTest < ApplicationSystemTest
  def setup
    host! "http://example.com"
  end

  def test_visit
    visit root_url # => visit "http://example.com/"

    visit "/" # => visit "http://127.0.0.1/"
  end
end
```

Because Capybara assumes that host is same as the server if we don't set `Capybara.app_host`:
https://github.com/teamcapybara/capybara/blob/866c975076f92b5d064ee8998be638dd213f0724/lib/capybara/session.rb#L239

Capybara drivers can handle some options such like `url`.

### before

```
# test/test_helper.rb
Capybara.register_driver :remote_chrome do |app|
  Capybara::Selenium::Driver.new(app, browser: :chrome, url: "http://example.com/wd/hub")
end

# test/application_system_test_case.rb
class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :remote_chrome
end
```

### after

```
# test/application_system_test_case.rb
class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :chrome, screen_size: [1400, 1400], options: {url: "http://chrome:4444/wd/hub"}
end
```

3 output types are supported:
- simple: only display the screenshot path
- artifact: display the screenshot in the terminal, using the artifact protocol (supported by some CI)
- inline (default): display the screenshot in the terminal, inline (supported by some terminals)

You can force the output type by setting the `RAILS_SYSTEM_TESTING_SCREENSHOT` environment variable

Previously the system test subclasses would call `driven_by` when the
app booted and not again when the test was initialized which resulted in
the driver from whichever class was called last to be used in tests.

In rails/rails#28144 the `driven_by` method was changed to run `use` on
setup and `reset` on teardown. While this was a viable fix this really
pointed to the problem that system test `driven_by` was a global
setting, rather than a per-class setting.

To alieviate this problem calling the driver should be done on an
instance level, rather than on the global level. I added an `initialize`
method to `SystemTestCase` which will call `use` on the superclass
driver. Running the server has been moved to `start_application` so that
it only needs to be called once on boot and no options from `driven_by`
were being passed to it.

This required a largish rewrite of the tests. Each test needs to utilize
the subclass so that it can properly test the drivers.
`ActionDispatch::SystemTestCase` shouldn't be called directly anymore.

Since using a browser is only for selenium it doesn't really make sense
to have a separate class for handling it there. This brings a lot of the
if/else out of the main SystemTestCase class and into the Driver class
so we can abstract away all that extra work.

This reverts commit 0d73f911, reversing
changes made to 21ff8a49.

We don't want to silence Puma because it's start up messages can be
useful (to see threads, port etc). #28109 was instead fixed by not
running system tests by defaul with `bin/rails test` in #28286.

Fixes #28109

`Capybara::RackTest::Driver` does not support taking screenshots. If call
`#save_screenshot` on `Capybara::RackTest::Driver` will raise the error.

```ruby
Error:
UsersTest#test_visiting_the_index:
Capybara::NotSupportedByDriverError: Capybara::Driver::Base#save_screenshot
```

To prevent errors, if driver does not support screenshot, do not call it.

If application has ajax, browser may begin request after rollback.
`teardown_fixtures` will be called after `super` on `after_teardown`
so we must call `Capybara.reset_sessions!` before `super`

https://github.com/rails/rails/blob/b61a56541aecd7ac685d4f19d943177a3f1b465a/activerecord/lib/active_record/fixtures.rb#L857

Now reset the driver before take failed screenshot since #28144.
However, I think that failed screenshot should be take with the driver
actually used in the test.
So, fixed to take screenshot before reset driver.

Previously, `driven_by` would change the Capybara configuration when
the test case is loaded, and having multiple test classes with different
`driven_by` configs would fail as the last loaded would be effective.

This renames the system test helper file to be application system test
case to match what the rest of Rails does. In the future we should
consider changing the test_helper to match.

* Override integration test default host

Integration tests automatically set the default host to
'http://example.com'. This works fine for integration tests because they
are not real browser sessions, but doesn't work fine for system tests
because they are real browser sessions.

We can override this by setting the `host!` in `before_setup. The
`Capybara.always_include_port` will allow the test to look at
`127.0.0.1:port capybara picks` and properly redirect the test.

Any application can override this by setting the `host!` in
their system test helper. Generally though, applications are going to be
using localhost.

In this commit I also moved the setup and teardown into their own module
for tidiness.

* Move teardown settings into system test case

These configuration options can be put into the system test case file
instead of the generated system tests helper file. This is an
implementation detail and therefore shouldn't be generated with the
template.