Ao3-7219 persist work preference after comment

[Dame-Zoom-A-Lot]

Pull Request Checklist

• Have you read "How to write the perfect pull request"?
• Have you read the contributing guidelines?
• Have you added tests for any changed functionality?
• Have you added the Jira issue number
  as the first thing in your pull request title (e.g. AO3-1234 Fix thing)
• Do you have fewer than 5 pull requests already open? If not, please wait
  until they are reviewed and merged before creating new pull requests.

Issue

https://otwarchive.atlassian.net/browse/AO3-7219

Purpose

Fix the bug where users who had "show the whole work by default" enabled were getting redirected to the full work view after commenting.

This was happening because of this line in the redirect_to_all_comments function

if commentable.is_a?(Chapter) && (options[:view_full_work] || current_user.try(:preference).try(:view_full_works))
   commentable = commentable.work
end

1. Commentable is always a chapter in multi-chapter works.
2. Regardless of options[:view_full_work], if user's preference has view_full_works set to true, (options[:view_full_work] || current_user.try(:preference).try(:view_full_works)) is always true

We also had bugs earlier in the code when setting options[:view_full_work]

In show_comments and add_comment_reply, options[:view_full_work] always evaluates as truthy regardless of whether it's 'true', or 'false', since params get evaluated as string values.

I simplified the logic by basing redirects on the previous page (referer) rather than the view_full_work param.

Based on manual test + looking at the code, I'm assuming that there's 3 ways to create / edit / delete a comment

1. From work view (/works/:id)
2. From chapter view (/works/:id/chapters/:id)
3. From comment view (/comments/:id)

I was concerned that by updating the logic so we no longer rely on params[:view_full_work], I'd break the flow from when a user deletes a comment from the comment view.

But I confirmed that we never set the view_full_work param when a user is navigated to to the comments path in both of the below cases:

1. User clicks Thread on a comment box, which navigates to the comments/:id path
2. User creates a reply beyond maximum comment thread depth, which navigates to the comments/:id path

We also did not set the view_full_work param when a user switched from entire work view to chapter view.

Since the view_full_work param is set unpredictably, and inconsistently, I believe it would be more maintainable if we consolidate all the logic to the redirect function and go off of where the user last was instead.

Testing Instructions

Please see Jira ticket - most recent test instructions are here with screenshots

References

This replaces an original PR: #5524

@Bilka2 thank you for your careful review. I agreed with your comment that the routing logic in the original PR was too convoluted, and that the simplest solution is to take the user back to where they were to begin with.

I was going to work off of my old PR, but it was so old that just starting from a clean slate was easier.

Credit

What name and pronouns should we use to credit you in the Archive of Our Own's Release Notes?

Zooms (any)

If you have a Jira account, please include the same name in the "Full name"
field on your Jira profile, so we can assign you the issues you're working on.

Please note that if you do not fill in this section, we will use your GitHub account name and
they/them pronouns.

[Dame-Zoom-A-Lot]

rubocop formatting changes

[Dame-Zoom-A-Lot]

Setting to draft mode while I add tests to default_rails_actions_spec