Fix #44: Add insecureTLSSkipVerify parameter to proxy config

[mishankov]

Summary

Closes #44

This PR adds support for skipping TLS certificate verification on a per-proxy basis through the new insecureTLSSkipVerify configuration parameter.

Changes

• Added insecureTLSSkipVerify field to Proxy struct in config
• Modified proxy handler to create custom HTTP client with TLS skip verify when enabled
• Added comprehensive test for insecureTLSSkipVerify functionality
• Updated README with documentation for the new parameter

Use Case

When proxying to HTTPS targets with self-signed or invalid certificates (common in development/testing environments), users can now enable insecureTLSSkipVerify for specific proxy routes instead of globally disabling TLS verification.

Configuration Example

[[proxy]]
prefix = "/api"
target = "https://api-server:8443"
insecureTLSSkipVerify = true

Testing

• ✅ All existing proxy tests pass
• ✅ New test verifies insecure mode works with TLS server
• ✅ Code compiles successfully
• ✅ Manual testing with self-signed certificates

Code Review Summary

No P0 or P1 blockers found.

Findings

[P2] HTTP Client Creation on Every Request

• Creating a new http.Client instance on every request when insecureTLSSkipVerify is true could impact performance under high load
• Recommendation: Consider caching the insecure client in future optimization if needed
• Not a blocker - acceptable for initial implementation

[P3] Missing Test for Default TLS Behavior

• No explicit test verifying normal TLS verification when insecureTLSSkipVerify is false
• Other tests implicitly verify normal behavior
• Not a blocker - acceptable coverage

Security Considerations

The feature is intentionally insecure (as the name suggests) but acceptable because:

• Opt-in per proxy route
• Clearly documented with security implications
• Common legitimate use case for development/testing
• User has full control

Known Limitations

• Performance: HTTP client created per request when insecure mode enabled (minor, can optimize later)
• Security: Users should avoid enabling in production environments

Checklist

• Code follows project conventions
• Tests added/updated
• Documentation updated
• All tests pass
• Code review completed