feat: contributor metric

[officialasishkumar]

Description

This PR introduces contributor metric feature, that records and stores the contributors information that are in different level to the database using a background process with the help of celery.

• d0: first fork or star/watch event.
• d1: first issue opened, first PR opened, first PR comment (within a configurable window).
• d2: longer-term flags and counts—PR merge, >5 issues opened, total comments, PRs with >3 commits, comments on >2 distinct PRs.

The final table includes:

• PK engagement_id, FKs repo_id, cntrb_id
• Contributor identity (username, full_name, country, platform)
• d0 flags and timestamp; d1 timestamps; d2 booleans and comment count
• Metadata columns (tool_source, tool_version, data_source, data_collection_date)

Indexes are on repo_id, cntrb_id, username, and platform.

This PR fixes #2992

Notes for Reviewers

Signed commits

• Yes, I signed my commits.

[MoralCode]

Hello @officialasishkumar, thanks for this contribution (and apologies for the delay in getting around to this).

We've made some fairly substantial changes to the repo (notably using uv for python dependency management). Could you rebase this PR on top of the current main branch? This should also fix a lot of the linter warnings.

[officialasishkumar]

Sure @MoralCode

Will do by the EOD

[MoralCode]

@officialasishkumar Rebasing would probably be a better way to update this PR so that the diffs are easier to review because they only contain the changes you made, rather than also containing code from other peoples unrelated PRs that already exist on the main branch.

Are you familiar with the process of rebasing in git? Happy to provide guidance if you would like

[Akshatb2006]

Hey @MoralCode
Could you please review this once??

[sgoggins]

FYI -- @MoralCode is out of office until early next week.

[sgoggins]

@officialasishkumar : New database objects should be in a file in {repo root}/augur/application/schema/alembic/versions

I think with the PR open for the other GSOC team the next number in sequence is 35.

That enables alembic upgrades and downgrade.

[officialasishkumar]

@sgoggins updated with commit 299bd90

[sgoggins]

Waiting for confirmation from @Ulincsys and @ABrain7710 ... but I think we don't modify the maindatabase creation script, and we do modify the version script ... so a person creating a new install gets all the old tables and your new ones last.

[sgoggins]

@ABrain7710 / @Ulincsys : Can you confirm that its our practice not to modify the main script for table creation, but to have the versioning script also included so that new installs just get "all the upgrades"?

[MoralCode]

The way i've done it in the past for other projects is that both the main schema gets modified AND migrations get created. Then if someone creates a new database, they get the latest schema (this has required a small bit of code when augur detects a new DB and creates the tables to stamp it with the current alembic version). Then that database can be upgraded as time goes on, but new dbs are always starting out on the latest version