Add redtext warning status to researcher session data

[mekline]

TL;DR

As a researcher, I want to know if the child was eligible for the study at the moment they started it Happily, this is identical to the logic performed to generate eligibility and resulting warnings on the search and study-detail pages. Can this information be injected into the Lookit session info so it's saved and included in the resulting data tables?

Desiderata -

• Add a new column to the session overview data download, named "eligibility"
• Levels should be "Eligible", or which of the messages was shown, e.g. "Ineligible_TooYoung", "Ineligible_TooOld", "Ineligible_Other" - or whatever possible values that redtext display can take on.

Acceptance criteria:

• Add a new 'eligibility' field/column to the Response model/table
• New response objects should get a value for the 'eligibility' field, which is a list with one or more of the 5 eligibility values (existing responses will not be changed - their values will be empty lists)
• Add explanation of this value to the data documentation: Add eligibility to response data docs lookit-docs#367
• Add tests

[becky-gilbert]

Comments/questions:

• The possible eligibility values (for the purpose of the participation warnings) are: Eligible, Ineligible_TooYoung, Ineligible_TooOld, Ineligible_CriteriaExpression, Ineligible_Participation.
• @mekline It's possible for a child to be ineligible for more than one reason. The way the warnings work is that we check for the following, and if any of these is true, display the warning message: (1) too young, (2) too old AND no other eligibility issues, (3) ineligible for other reasons (criteria expression and/or participation requirements). If we're going to add this value into the response data, we'll need to know how to handle cases where multiple ineligibility criteria is met. Does one take priority? Do we need categories for each combination?

Implementation notes:

I think the relevant place to do these checks is in web/views.py, in StudyDetailView and in the dispatch method. This is where we handle the 'participate/preview' button click request and redirect to the experiment. This way we can use the existing eligibility check methods in accounts/queries.py (get_child_eligibility_for_study etc.).

Another option for this might be in the API's ResponseViewSet, e.g. at the point when the first Response object from a study is created.

It would also be possible to add this data into the response object from within EFP, but I don't think the EFP has access to all of the information it would need (e.g. all of the child's prior study participation, the study's criteria expression and prior participation requirements). So I don't think we should go this route.

[mekline]

How about a bracketed list of reasons? e.g. {TooYoung, Ineligible_CriteriaExpression, Ineligible_OtherStudyParticipation} or {} or {Ineligible_CriteriaExpression} as appropriate?

[mekline]

Actually for style consistency, we should match this to how we handle multiple "other info" criteria, which shows up in the researcher tables with a value like

autism_spectrum_disorder hearing_impairment

So the equivalent here would be

too_young ineligible_criteria_expression ineligible_other_study_participation