Refactor NotificationMailer to use parameterization

[mjankowski]

These methods were all pretty similar with a lot of common setup, so I extracted that into a parameterized setup using with when the mailer is called and before_actions in the mailer to set i-vars.

Also did some readability refactor in the spec and preview while in there.

If diff seems excessive - going one commit at a time is probably more sensical.

I think the Admin and User mailers both have similar opportunity and will do those after this if merged.

[ClearlyClaire]

Doesn't it break jobs queued after the code change?

[mjankowski]

I'm not sure! My original thought was that it would be ok because we didn't explicitly change any job method signatures ... but here's more research...

Rails 7-0 branch, regular MessageDelivery enqueuing delivery -- https://github.com/rails/rails/blob/7-0-stable/actionmailer/lib/action_mailer/message_delivery.rb#L143

Same thing but in the parameterized class -- https://github.com/rails/rails/blob/7-0-stable/actionmailer/lib/action_mailer/parameterized.rb#L144

The parameterized version calls perform_later with an extra params arg, which would mean:

• This value would be absent in any jobs sitting in queue to be retried, and thus not passed in to new code once reload/restart happens
• Old jobs in queue would have MORE items in args than the new code expects, which might also trip it up

So, I think maybe it is an issue. Is there typically a large backlog of mailer jobs?