add go mod replace support

[willie-yao]

What this PR does / why we need it:
Continuation of #847

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):
Fixes #

Special notes for your reviewer:

[willie-yao]

This change exposes the error of the state to the user as this is in an error check

[Copilot]

Pull request overview

This PR adds support for go mod require and replace directives in the gomod generator, allowing users to programmatically modify go.mod files during the build process. This is a continuation of #847 and enables important use cases like replacing dependencies with forks, working with multi-module repositories, and pinning specific dependency versions.

Key Changes:

• New GomodEdits, GomodReplace, and GomodRequire types for declarative go.mod manipulation
• Preprocessing logic that generates patches from gomod edits before building
• Internal SourceLLB type for programmatically generated patch sources
• Validation and extensive test coverage for the new functionality

Reviewed changes

Copilot reviewed 20 out of 20 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
website/docs/sources.md	Documents the new gomod replace/require directives (contains format errors that need correction)
spec.go	Defines GomodEdits, GomodReplace, and GomodRequire types with marshaling/unmarshaling logic
preprocess.go	Implements preprocessing logic to generate patches from gomod edits
source_llb.go	Introduces internal-only SourceLLB type for programmatically generated sources
source_generated.go	Generated code for SourceLLB integration
source.go	Integrates LLB field into Source type
load.go	Adds validation for gomod edits
generator_gomod_test.go	Unit tests for unmarshaling and validation of gomod directives
spec_test.go	Validation tests for SourceGenerator gomod edits
test/source_test.go	Unit tests for gomod require/replace with debug/patched-sources target
test/linux_target_test.go	Integration tests for gomod edits across different scenarios
test/fixtures/simple-go-require.yml	Example fixture demonstrating correct usage
targets/windows/handle_zip.go	Adds Preprocess call before building
targets/linux/rpm/distro/pkg.go	Adds Preprocess call before building
targets/linux/deb/distro/pkg.go	Adds Preprocess call before building
targets/linux/distro_handler.go	Standard import reordering
frontend/gateway.go	Standard import reordering
frontend/debug/handle_sources.go	Adds Preprocess call before getting sources
docs/spec.schema.json	Updates JSON schema with new gomod edit types
docker-bake.hcl	Removes trailing blank line

[cpuguy83]

So this injects totally new requires?

[willie-yao]

I think so. Is that a concern or should we be doing this a different way? @DannyBrito can maybe also clarify since he wrote the original struct.

[cpuguy83]

I guess the main thing is, do we have a use-case for this right now?

[DannyBrito]

sorry I missed this but tbh I don't really understand the question here; I reused initial implementation of the GomodEdits https://github.com/project-dalec/dalec/pull/769/changes#diff-f23a639898f3d395e15d7331eeab9d8d6217fe161c2851610171da61d9f92dd5R255.

[cpuguy83]

Basically, do we need to support adding new requires in this feature.

[sozercan]

we don't need to inject new requires since they'll get cleaned up by go mod tidy

we should only use require to update existing requires. require: old:new, not require: new

[cpuguy83]

@willie-yao This one needs a rebase to get CI fixes and I think one merge conflict?

[willie-yao]

@cpuguy83 The test failures seem to be still related to runners not having enough memory. Otherwise CI looks good?

[cpuguy83]

For the string format, I think we should either drop it or do the exact format that go.mod uses ( old/mod/path => new/mod/path version)