Many pages had this tag, but many other didn't, which made navigation
inconsistent for people using screen readers.
Note that there are slight changes in two pages:
* The homepage now includes the banner and the content of the
`shared/header` element inside the <main> tag
* The budgets index now includes the banner inside the <main> tag
I see both potential advantages and disadvantages of this approach,
since banners aren't necessarily related to the main content of a page
but on the other hand they aren't the same across pages and people using
screen readers might accidentally skip them if they jump to the <main>
tag.
So I'm choosing the option that is easier to implement.
Note we're adding a `public-content` class to the <main> element in the
application layout. This might be redundat because the element could
already be accessed through the `.public main` selector, but this is
consistent with the `admin-content` class used in the admin section, and
without it the <main> element would sometimes have an empty class
attribute and we'd have to use `if content_for?(:main_class)` or
`tag.main` which IMHO makes the code less consistent.
The Capybara::DSL monkey-patch is only done on the `visit` method
because it's the only reliable one. Other methods like `click_link`
generate AJAX requests, so `expect(page).to have_css "main", count: 1`
might be executed before the AJAX request is finished, meaning it
wouldn't properly test anything.
In the management section, `current_user` is the user impersonated by
the manager. We were deciding whether to show the admin menu depending
on the privileges of the current user, but this menu should be shown
according to the privileges of the manager who is impersonating the
user.
We're doing a similar (very subtle) change in the login items. We were
rendering the `login_items` partial passing `current_user: user`.
However, inside this method, we were using `user_signed_in`, which
ignored the `current_user` we were passing. The result was always the
same expect in tests where we manually sign in users, but we're changing
it anyway in order to reduce confusion.