Auto-close conditionals where child resolved before parent

[hlbmtc]

Revisited auto-close logic for conditional questions:

• Added PredictionStatusMessage: it refactors Forecast Maker predictionMessage component and generates status message JSX instead of string lang.
• Fixed Post.set_actual_close_time logic for conditional questions: not it auto-closes parent if Condition OR Child was closed
• Fixed PostReadSerialize.get_status generation. Now it respects actual_close_time dates
• Configured pytest to reuse db
• Extra unit tests

TODO:

• Write a local migration to close all questions where conditional parent was resolved, but child is still active
• Apply ad-hoc script on prod

closes #1008

[lsabor]

I don't think there should ever be a state where there is one close and one open branch?
What situation are you imagining?

[lsabor]

If we're already in the PostStatus.CLOSED situation, then how would there be an active branch question?

[lsabor]

This just seems like unreachable code, so not blocking, just unnecessary

[hlbmtc]

@lsabor
It's not about Yes/No branches, but condition parent and condition child.
We have an example of this -- https://www.metaculus.com/questions/22051/starship-booster-tower-catch-attempt-in-2024/

#1008

[lsabor]

Good tests

This might be asking you to do my work for me, but it would be great to have tests for "unresolve" parent / child actions as well.

[hlbmtc]

Sure. I added a test case base, so you could expand it in the future. Though, I probably found a bug:
https://github.com/Metaculus/metaculus/pull/1543/files#diff-8f63f33d62c6c58b08f8ab06d0171c596d83d352ab6619e3b140831b779f9e65R132-R133

[lsabor]

Looks good to me.
I left a comment on prediction_status_message that should be looked at, but not blocking.
The other thing is optional addition of tests for conditional question unresolve. (If you don't want to do it, I can add those tests in a later PR).