Refine "overdue" and introduce new "deactivated" subscription state

[olmari]

Overview:

Overdue state needs to allow door access, and after that there could be new "deactivated" status before suspended. Bigger enhancement instead of just fixing overdue behaviour in: https://github.com/TampereHacklab/mulysa/issues/386, allowing more control over individual hacklab needs.

Reasoning:

Humans are humans and sometimes forget things, there needs to exist some leeway between payment overdue and door access not working. Also mispayments can happen and sometimes clerical error from hacklab side. Also money still can take 2 banking days to arrive, and banking data is currently not anywhere near to real time either.

Logic-flow:

• After active days ends, change status to overdue, keep allowing door access
  • Time perioid configurable
• After overdue days ends, change status to deactivated, deny door access, user can still catch up with payments without administrative intervention
  • Time perioid configurable
• After deactivated days overdue, change status to suspended, needs administrative intervention to remediate.
• Send remainders when states change (also keep the current pre-warning on active as is)

Technical workflow:

One way: Logic in overdue and deactivated works pretty similarly, overdue allows door acess, deactivated doesn't, comes one after another.

• Current "overdue" could be literally renamed as "deactivated" and test working (as current overdue function is actually deactivation by nature)
• Introduce new overdue which functions mostly the same as current overdue, exept allow door to open still
• Overdue time field in Member service settings needs rewording: "How many days service can be in overdue until it is moved to deactivated state"
• Needs new field inside Member service settings, "How many days service can be in deactivated state until it is moved to suspended state"
• Both overdue and deactivation time fields could be set to null/blank (not set) or 0, effectively skipping that status entirely, not everything is applicable to every hacklab and every service hacklab might offer.
• Make sure sure logic flow uses correct settings, so flow actually is correctly from active -> overdue -> deactivated -> suspended

[vranki]

Just a comment to "Overdue state needs to allow door access". This is incorrect, overdue state means the payments are overdue and door must not open until new payment is detected. This works as expected with current state definitions. The idea is to have buffer for import delays and warn user before entering overdue state. But feel free to re-define the states if needed. Just test really well as state machine can be error-prone.