* see thoughtbot#916
* similar to thoughtbot#909
* also see GHSA-hrqr-hxpp-chr3
  for an example of the type of attack that could be possible with an
  injectable cookie value
* Rails provides signed cookies https://api.rubyonrails.org/classes/ActionDispatch/Cookies.html
  since Rails 3 (??) which prevents tampering
* using a signed cookie instead of a plain one, means the attacker cannot
  forge the cookie value, and therefore cannot perform timing attacks
  to find a valid token
* another added value is that tampering with the cookie will
  not even hit the database
* added a configuration parameter `signed_cookie` so this is optional
  and defaults to false for backwards compatibility
  (however, for better security, it might be better to issue a breaking
   change and default to true)
* changed the add_cookies_to_headers method to use ActionDispatch /
  Rails' cookie-handling code to set the cookie
* updated specs

* the configuration value for signed_cookie can be set 3-ways:
  - `false` (default): backwards compatible, insecure
  - `:migrate`: converts unsigned cookies to signed ones
  - `true`: forces using signed cookies only
* these 3 options would allow users to transition to signed cookies
  and also the project to gradually change the default
* updated specs + added "validation" inside the configuration class
  to allow only those 3 values

Co-authored-by: Eebs Kobeissi <[email protected]>

…ngerlime/clearance into prevent_remember_token_timing_attacks

… prevent_remember_token_timing_attacks