updates to chainlink tool

[SharpRake]

Type of change

Enhancement

This PR adds new functionality to the chainlink tool for improved link checking and
validation.

What should this PR do?

resolves https://github.com/chainguard-dev/internal/issues/5442

Why are we making this change?

The chainlink tool needed enhanced capabilities for link checking to better handle edge
cases and improve reliability when validating links in documentation.

What are the acceptance criteria?

• New link checking functionality is implemented in links.go
• Comprehensive test coverage added in links_test.go
• All existing tests continue to pass
• Binary builds successfully

How should this PR be tested?

1. Build the chainlink tool: cd tools/chainlink && go build
2. Run the test suite: go test -v
3. Test the tool against sample documentation with various link types
4. Verify all tests pass and the tool handles edge cases correctly

[netlify]

✅ Deploy Preview for ornate-narwhal-088216 ready!

Name	Link
🔨 Latest commit	766b146
🔍 Latest deploy log	https://app.netlify.com/projects/ornate-narwhal-088216/deploys/695810c0f498680008494709
😎 Deploy Preview	https://deploy-preview-2662--ornate-narwhal-088216.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[ltagliaferri]

My commit added:

1. Remove insecure TLS verification fallback

• Delete the TLS relaxed verification code block (lines ~199-217 in the PR)
• Remove the isTLSError() helper function
• Update shouldTryFallback() to exclude TLS-related conditions

2. Extract common HTTP request creation logic into helper function

• Create a new createRequest(method, url string) helper that sets User-Agent and Accept headers
• Replace all 8+ instances of duplicated request creation code
• This will reduce ~40 lines of repetitive code

3. Replace goto statements with structured error handling

• Refactor the fallback logic to use helper functions that return success/failure
• Replace the processResponse: label and goto jumps with early returns or result structs
• Make the control flow more readable and maintainable

4. Replace string-based error checking with type assertions where possible

• Update error detection to use errors.As() or type switches for proper error types
• Keep string matching only where necessary (for wrapped errors without types)
• More robust across Go version changes

5. Implement logging levels (add -verbose flag, reduce default output)

• Add a -verbose flag to control output verbosity
• Keep important errors/warnings visible by default
• Move debug messages (like "trying fallback strategy") behind verbose flag

6. Add timeout/circuit breaker for fallback strategies

• Add a maximum retry limit per link (e.g., max 2 fallback attempts)
• Consider adding request timeouts for fallback attempts
• Prevent excessive delays when checking broken links

Some other items than can be added in the future:

Add command-line flag for trailing slash fallback behavior

• Add a new flag like -try-trailing-slash (default: false)
• Only attempt trailing slash fallback when this flag is enabled
• This prevents masking legitimate broken links by default

and

Expand test coverage for redirect loops, error conditions, and new flags

• Add test for redirect loop fallback behavior
• Add tests for the new -try-trailing-slash and -verbose flags
• Add tests for error type detection improvements
• Test timeout/circuit breaker behavior