FIx Finding Housekeeping Candidates and Modify Housekeeping Structure

[devleejb]

What this PR does / why we need it:

• Refactored the FindDeactivateCandidates function, moving it from the Database Layer to the Service Layer
  • Due to the change in the function's layer, the Housekeeping-related tests from the Database Layer have been relocated to Integration Tests
• Changed function name from listProjectInfos to FindNextNCyclingProjectInfos
• Changed the implementation of the FindNextNCyclingProjectInfos function to retrieve a cyclic list of N projects with IDs greater than lastProjectID
• Fix FindDeactivateCandidatesPerProject for memdb to return candidates of only one project

Which issue(s) this PR fixes:

Fixes # #744

Special notes for your reviewer:

• Considering whether initializing the database in the Integration Test is the right approach.
• Concerns arise due to the absence of clear code for each Unit Test, potentially leading to data dependency issues.
• There is a remaining function FindDeactivateCandidatesPerProject in the Database Layer. Seeking opinions on whether it would be appropriate to rename it to something unrelated to Housekeeping.

Does this PR introduce a user-facing change?:

NONE

Additional documentation:

Checklist:

• Added relevant tests or not required
• Didn't break anything

[codecov]

Codecov Report

Attention: 33 lines in your changes are missing coverage. Please review.

Comparison is base (3b712df) 49.30% compared to head (6ad2ca3) 49.35%.
Report is 3 commits behind head on main.

Files	Patch %	Lines
server/backend/housekeeping/housekeeping.go	0.00%	20 Missing ⚠️
server/backend/database/memory/database.go	66.66%	4 Missing and 3 partials ⚠️
server/backend/database/mongo/client.go	64.70%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #749      +/-   ##
==========================================
+ Coverage   49.30%   49.35%   +0.04%     
==========================================
  Files          69       69              
  Lines       10094    10113      +19     
==========================================
+ Hits         4977     4991      +14     
- Misses       4601     4606       +5     
  Partials      516      516              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[krapie]

I'm curious if there are ways to leverage the features of the Go language to further improve the code in a cleaner way.

I can't think of anything beyond what you've written, other than using a for statement to
simply code (maybe?) or refactoring redundant querying codes. I didn't find any syntax for circular queries in MongoDB either.

We can temporary apply this changes to fix urgent error, and then consider housekeeping service structure to improve overall housekeeping structure & performance.

Any ideas? @hackerwins

[devleejb]

@krapie

I can't think of anything beyond what you've written, other than using a for statement to simply code (maybe?) or refactoring redundant querying codes. I didn't find any syntax for circular queries in MongoDB either.

I'm unfamiliar with Go lang, and I had concerns about whether the code could be simplified using techniques specific to the language. Thank you.

[krapie]

Can you request review after you open this PR? It seems like this is still in progress.

[krapie]

Thank you for your contribution.

Refactored housekeeping service structure & test looks better than before 👍🏼
I have requested few convention-related changes.

[krapie]

LGTM.

[krapie]

@devleejb
Leaving few more comments on your notes:

Considering whether initializing the database in the Integration Test is the right approach.

initializing on top of the test function looks better than rentention_test.go.

Concerns arise due to the absence of clear code for each Unit Test, potentially leading to data dependency issues.

RunFindNextNCyclingProjectInfosTest() and RunFindDeactivateCandidatesPerProjectTest() test codes in testcases.go will do its job for now.

There is a remaining function FindDeactivateCandidatesPerProject in the Database Layer. Seeking opinions on whether it would be appropriate to rename it to something unrelated to Housekeeping.

This function can be only used for housekeeping purposes, and cannot normalize more. So I think name FindDeactivateCandidatesPerProject() is appropriate.