feat(users/services): Local groups cleanup

[denisonbarbosa]

Due to limitations with our cache, we can't know exactly which users were deleted when the database was corrupted and it got cleared up and rebuilt, so we need to have a routine that periodically cleans the local groups from any unexistent users.

This is a complex task that could potentially spawn a lot of subprocesses (in the form of gpasswd --delete calls) to clean the local groups. However, the dominant factor of complexity in the code is the number of groups (and the number of users that belong to those groups) rather than the number of existent users. Since we query directly /etc/groups to look for the groups, we are only dealing with local groups here and, as such, we should be fine with performance.

UDENG-1864

[didrocks]

Ok, apart from the lack of getent mocking which actually explains why there is only one positive use case and less granularity, the rest of the actual internal/users/ implementation looks good.

However, I didn’t review internal/services/: thinking about it, I changed a little bit my vision and I think we can do better in term of handling and when triggering all of this so that this routine is exceptional:

• we should still try, when removing an user from a consistent database (because of expired cache), to clean the local groups this user is in. This is the normal procedure and we know exactly which user is currently under purge, and remove it.
• I really see that as a fallback when the database is seen as corrupted and we shouldn’t attempt anything until getting a "database is corrupted" signal. That way, cleaning the user from system group will become again just a part of the corrupted database cleanup and will not be called more than this. It’s then decoupled from the manager.

Mind reworking this PR to follow this?

[codecov-commenter]

Codecov Report

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

Comparison is base (b92fb6a) 88.83% compared to head (3c81c49) 88.98%.

Files	Patch %	Lines
internal/users/users.go	92.85%	3 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #150      +/-   ##
==========================================
+ Coverage   88.83%   88.98%   +0.15%     
==========================================
  Files          35       36       +1     
  Lines        2650     2733      +83     
==========================================
+ Hits         2354     2432      +78     
- Misses        228      231       +3     
- Partials       68       70       +2     

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

[didrocks]

Is that really ready for review? I still see the manager/ directory calling the users one when we agreed to remove all this for this PR?

[didrocks]

Please, really take the time to look at what is needed or not, and then only, request for review. Look at the diff on github if the local diff is too hard to read, but take the time to do ensure it to give confidence on the review.

[didrocks]

Here is your review! This time, no undeed leftor, but still some work to do and open questions! Feel free to tell me if anything is not understandable.

[didrocks]

Ok, only one real comment with 2 parts remaining! If you look at the coverage (you do, right?), there should be the Go-C function that is lacking coverage, right? I mentioned yesterday that we should unit test it (even if it’s going to be basic, still better than nothing).

Otherwise, it’s funny to see how this cgo part simplify the code in the end (less parsing, easier to test…)

[didrocks]

This is still not an unit test :p So not the last round, but next one should be!

[didrocks]

Good to me once the test pass and is commits are rebased!