[FEATURE]: Introduce URI allow-list for HttpTask to mitigate SSRF

[RinZ27]

Pull Request type

• Bugfix
• Feature
• Refactoring (no functional changes, no api changes)
• Build related changes
• WHOSUSING.md
• Other (please describe):

Changes in this PR

The current HttpTask implementation allows arbitrary HTTP requests to any URI provided in the workflow definition. This poses a significant security risk in multi-tenant or enterprise environments, as it could be exploited for Server-Side Request Forgery (SSRF) to probe internal networks or access sensitive metadata services (e.g., AWS/GCP metadata endpoints).

I've introduced a configurable URI allow-list mechanism using regular expressions. This allows administrators to restrict the set of URIs that HttpTask is permitted to interact with.

• Added HttpTaskProperties to manage the conductor.tasks.http.urlAllowList configuration.
• Implemented URI validation logic in HttpTask that checks the destination URI against the configured allow-list.
• If the allow-list is configured and a URI does not match, the task fails with a FAILED_WITH_TERMINAL_ERROR and a clear security violation message.
• Maintained backward compatibility: if the allow-list is empty (default), all URIs are allowed.

Alternatives considered

Considered implementing a hardcoded block-list for common metadata endpoints, but a configurable allow-list provides better flexibility and security for varying network architectures.

[RinZ27]

Fixed the unit test failure in HttpTaskUnitTest.

The security validation tests were making real network calls to external domains, which caused UnknownHostException in environments without internet access or with strict firewalls. I've mocked the httpCall method using a Mockito spy to ensure the security policy logic is tested in isolation without side effects.

Verified all tests in conductor-http-task are passing locally.