refactor(source/engine): move link generation and update from engine to source specific functions

[amanfcp]

Description:

Changes:

• Add UpdateLink function pointer to Chunk struct for source-specific link updates
• Implement generateLink and updateLink functions in GitHub source for all repo types
• Extract common URL manipulation helpers to pkg/giturl/helpers.go
• Update engine.go to call chunk.UpdateLink directly instead of UpdateLink function
• Mark SupportsLineNumbers as deprecated (used for backward compatibility only)
• Update Git source to pass UpdateLink function pointer from configuration
• Add unit tests for GitHub link generation and updating

End Goal & Future Work

Current State (This PR)

• GitHub only: Implements source-specific link generation via function pointers
• Other sources: Fall back to centralized giturl.GenerateLink() / UpdateLink()
• Engine: Checks chunk.SourceUpdateLink != nil first, then falls back to SupportsLineNumbers()

Final State (After All Iterations)

// Sources own their link logic
github.Init() → sets UpdateLinkFunc: s.updateLink
gitlab.Init() → sets UpdateLinkFunc: s.updateLink
bitbucket.Init() → sets UpdateLinkFunc: s.updateLink

...

// Engine stays simple
if chunk.SourceUpdateLink != nil {
    updatedLink := chunk.SourceUpdateLink(link, line)
    // Done. No provider detection needed.
}

What Gets Removed

• giturl.GenerateLink() - each source implements its own
• giturl.UpdateLinkLineNumber() - replaced by source functions
• SupportsLineNumbers() - replaced by nil check
• Provider detection logic in giturl package

Note:

We can also remove the giturl package entirely and move the helper functions elsewhere.

Once this gets approved, we can iteratively implement this on all git flavored sources and remove the deprecated functions entirely.

Checklist:

• Tests passing (make test-community)?
• Lint passing (make lint this requires golangci-lint)?

[amanfcp]

A mismatch was identified between how line number support is defined and how metadata links are handled. SupportsLineNumbers() indicates that 9 source types support line numbers, but updateMetaDataLink() only implements logic for 5 metadata types. As a result, sources like GERRIT are marked as supported but have no corresponding metadata handling, causing them to fall through to the default error case.

[mustansir14]

Instead of duplicating the logic for this else if block, can we add an || in the first if condition? Then when calling the link update function, we can add a smaller if else check.

[amanfcp]

Yeah the duplication is messy but I was just trying to avoid nested ifs and making as few changes as possible in the previous flow (since it's temporary code if this gets approved)

[mustansir14]

Duplication like this can cause maintenance issues. This block already has one nested if so another one wouldn't increases the complexity level IMO

[mustansir14]

I'm wondering if it makes sense to have these Github-specific helpers in the giturl package. If they are only used by the Github source, can we move them there?

[mustansir14]

I'm concerned about the name of the field. I feel like it doesn't clearly explain the purpose. If it specifically deals with line numbers, can we call it UpdateLinkLineNumber?

[amanfcp]

FYI, I intentionally added Source prefix here like other source specific fields in this struct. SourceUpdateLinkLineNumber seems a bit unnecessarily specific don't you think?

[mustansir14]

I just felt that SourceUpdateLink is a very generic term and doesn't clearly define what sort of updation will happen. But on the other hand the function signature takes in line int64 so I guess we're fine...

[mustansir14]

Looks good to me overall. A few minor suggestions/concerns.

[mustansir14]

Also once this approach is finalized and merged in, we should create tickets to migrate other sources to this new pattern as well, with the purpose of completely removing the generic link generation/updation logic.

[amanfcp]

This test is failing. Not sure why we have a fixed size match so just putting it out here.