feat: support customize the job execution retention count by env

[chlins]

This pull request introduces a new utility function for reading environment variables and updates the job execution retention logic to use environment-configurable values. It also includes comprehensive unit tests for the new utility function. Below are the most important changes:

New Utility Function for Environment Variables

• Added GetEnvInt64 function in src/lib/env.go to read environment variables as int64 with a default fallback value. This ensures flexibility in configuring values through environment variables.

Refactoring of Job Execution Retention Logic

• Updated the executionSweeperCount map in src/jobservice/job/known_jobs.go to use the GetEnvInt64 function for fetching retention counts from environment variables. This allows dynamic configuration of retention counts without changing the code.
• Imported the lib package in src/jobservice/job/known_jobs.go to utilize the new utility function.

Unit Testing for the Utility Function

• Added src/lib/env_test.go with comprehensive test cases for GetEnvInt64, covering scenarios such as valid values, unset variables, invalid values, zero, negative, and large numbers. This ensures reliability and correctness of the function.

Thank you for contributing to Harbor!

Comprehensive Summary of your change

Issue being fixed

#20777

Please indicate you've done the following:

• Well Written Title and Summary of the PR
• Label the PR as needed. "release-note/ignore-for-release, release-note/new-feature, release-note/update, release-note/enhancement, release-note/community, release-note/breaking-change, release-note/docs, release-note/infra, release-note/deprecation"
• Accepted the DCO. Commits without the DCO will delay acceptance.
• Made sure tests are passing and test coverage is added if needed.
• Considered the docs impact and opened a new docs issue or PR with docs changes if needed in website repository.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 65.89%. Comparing base (c8c11b4) to head (e9a58d7).
Report is 500 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main   #22129       +/-   ##
===========================================
+ Coverage   45.36%   65.89%   +20.52%     
===========================================
  Files         244     1072      +828     
  Lines       13333   115713   +102380     
  Branches     2719     2925      +206     
===========================================
+ Hits         6049    76246    +70197     
- Misses       6983    35243    +28260     
- Partials      301     4224     +3923     

Flag	Coverage Δ
unittests	65.89% <100.00%> (+20.52%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/jobservice/job/known_jobs.go	0.00% <ø> (ø)
src/lib/env.go	100.00% <100.00%> (ø)

... and 984 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Vad1mo]

Why is this config option bypassing config.go, and the usual way of on how new configuration options are introduced into Harbor?

[chlins]

Why is this config option bypassing config.go, and the usual way of on how new configuration options are introduced into Harbor?

@Vad1mo Currently, not all configurations go through config. The configurations that do are generally focused on a specific function and need to be exposed to users during deployment and installation. However, some configurations don't necessarily need to be exposed—they might just be advanced settings that most users don't need to customize. Adding another config layer in such cases would actually increase complexity and maintenance costs. In my opinion, these configurations are just custom needs for a small number of users and won't be reused elsewhere, so directly reading environment variables is the simplest approach.

[wy65701436]

lgtm