Bug withdrawn application backend

[Snorre98]

⭐ alot lines added are comments and doc strings! ;-) 400 lines are tests

👁️ seed script was viloating validation in the refactored RecruitmentApplication model

What

This PR refactors the RecruitmentApplication model. I found a bug which caused the applicants prioitiy of positions to "come out of sync". This PR fixes this bug by adding constraints to the RecruitmentApplication model, as well as refactors the save and clean methodes.

Why

First of all; when an application was withdrawn the "active applications" count was not updated. Therefor it as possible to set position priority on a scale of "all applications" including withdrawn applications.
This would cause the priority to not be deterministic. By refershing the page, a new query would be made which fethced the correct priority sequence, but by reprioritizing the priority sequence could come out of sync again.

New validation and helper methodes in RecruitmentApplication

RecruitmentApplication became extencive because I created helper methodes for almost everything. I also added some validation which should have been implemented before, like validation constrains for reprioritization deadline and priority deadline for recruitment admins.

The logic for update_applicant_state is unchanged.

get_total_interviews is unchanged

get_total_applications is unchanged

Views and tests

Views

Some of the views related to fetching applications for applicant where also refactored.

• RecruitmentApplicationForApplicantView now only gives non-withdrawn applications. There is a view dedicated to getting withdrawn applications.

• RecruitmentApplicationWithdrawApplicantView was extended with a get methode

• RecruitmentApplicationApplicantPriorityView was refactored to work with the refactored RecruitmentApplication model better

Tests

• test_withdrawn_application_priority_handling test that priorities are properly managed when applications are withdrawn
• test_reapplying_after_withdrawal_priority test that reapplying after withdrawal gets correct priority
• test_priority_constraints_with_withdrawn_applications test that priorities stay within bounds of active applications only
• test_multiple_withdrawals_and_priorities test complex scenario with multiple withdrawals and reapplications
• test_recruiter_priority_update_before_deadline test that recruiter can update priority before the deadline
• test_recruiter_priority_update_after_deadline test that recruiter cannot update priority after the deadline
• test_deadline_validation_with_multiple_applications test deadline validation with multiple applications
• test_applicant_update_application_priority_before_deadline Test that applicant can update their application priorities before the deadline
• test_applicant_update_application_priority_after_deadline Test that applicant cannot update their application priorities after the applicant reprioritization deadline
• test_applicant_priority_remains_sequential Test that application priorities remain sequential (1,2,3...) when updated
• test_deadline_validation_constraints Test application validation against recruitment timeline deadlines
• test_priority_validation Test validation of application priority assignments
• test_reorder_priorities_edge_cases Test edge cases in priority reordering logic

Replaces backend part of #1542

closes #1535

[Mathias-a]

idk se på litt

[Mathias-a]

What does this even mean?

[Mathias-a]

Why?

[Mathias-a]

Denne syntes jeg er rar. Er det ikke mulig å sammenlikne args med nåværende tilstand?

[magsyg]

Hvordan er denne over 1000 linjer lang wut

[magsyg]

Hmmm ser ganske greit ut, men burde nok egt vært flere issues, ser ut som dette er en stor refactor av application og modulasering med _ functionene