Add InfoRequestEvent#pro

[gbp]

Relevant issue(s)

What does this do?

Add InfoRequestEvent#pro

Why was this needed?

This will be useful for showing impact of the Pro service.

For example showing how many citations have been created for pro/non-pro requests.

Implementation notes

Initial implementation was to add a completely separate event which was created when a InfoRequest was first created.

Instead now, I've opted to record if the user was a pro on each InfoRequestEvent, as this might give us more insight in to actions carried out - for example if an embargo expires while the Pro is still a subscriber or if the Pro is following up or classifying their requests after their subscription has lasped.

Screenshots

Notes to reviewer

[garethrees]

I haven't looked through this in depth yet, but this, alongside the thought of tracking sign_ups_ as well as sign_ins_ (#6822 (comment)) did prompt me to write up some thoughts on extracting some more generic domain components (#6931).

One of those is an Event class that can be applied to any appropriate model. With that in mind, I'm not totally sure that adding a new attribute directly on InfoRequestEvent makes sense. I'm not totally against it as it solves a problem for now, but it's worth us thinking about if we can avoid some pain here.

Did you look in to adding a new key in the params_yaml (#6594 (review))? It feels like whether an event was generated while the user was a pro is more incidental, but I appreciate that might currently make the querying more difficult. With the above approach of a generic Event class I think we'd want to move the params to a jsonb column or ActiveRecord::Store, though again I appreciate that doesn't help us right now.

[garethrees]

Decided the next thing to do here is address moving params_yaml to jsonb as part of #6341.

[garethrees]

Closed to reduce overwhelm of high WIP. Can reopen in the future if necessary.