Add Confluence Data Center support with allow_local_address and beare…

[srikanthpadakanti]

Description

Two changes to support Confluence Data Center deployments:

1. Configurable address validation (allow_local_address)

The existing AddressValidation.validateInetAddress() rejects all local/private IPs, which blocks Confluence Data Center running on internal
networks. Added a boolean config allow_local_address (defaults to false) that skips site-local, loopback, and link-local checks when enabled.
Multicast and any-local addresses are still rejected regardless.

  source:
    confluence:                                                                                                                                     
      hosts:                                                                                                                                        
        - "https://confluence.internal.company.com"                                                                                                 
      allow_local_address: true                                                                                                                    

2. Bearer token authentication

Confluence Data Center uses Personal Access Tokens (PAT) for authentication. Added bearer_token as a third auth option alongside basic and oauth2.
Only one auth method can be configured at a time.

  source:                                                   
    confluence:
      hosts:                                                                                                                                        
        - "https://confluence.internal.company.com"
      allow_local_address: true                                                                                                                     
      authentication:                                       
        bearer_token: "your-personal-access-token"           

Changes are in atlassian-commons so Jira Data Center also benefits from the same allow_local_address and bearer token support.

Issues Resolved

Resolves #6496
#6496

Check List

• [ X ] New functionality includes testing.
• New functionality has a documentation issue. Please link to it in this PR.
• [ X ] New functionality has javadoc added
• [ X ] Commits are signed with a real name per the DCO

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[srikanthpadakanti]

Hi @dlvenable @kkondaka Please review this. Thanks.

[dlvenable]

Thanks @srikanthpadakanti for the contribution! I have a few comments and questions.

[dlvenable]

For OAuth2, we use PluginConfigVariable. This allows us to refresh the credentials from the Jira/Confluence source plugins themselves. Do you think this is relevant for bearer tokens?

Either way, this can support reading from secrets managers.

[srikanthpadakanti]

Agreed on PluginConfigVariable, Will address in a follow-up since PATs don't need refresh, but secrets manager reads are valuable. Keeping scope tight for this PR.

Otherwise if you want me to implement it now, I can change String bearerToken to PluginConfigVariable bearerToken and update all usages. What do you prefer?

[dlvenable]

We support two forms of refresh:

1. Somebody outside of Data Prepper updates the secret in something like AWS Secrets Manager
2. Data Prepper refreshes the secrete and updates the secret in AWS Secrets Manager

For OAuth2, we support number 2.

For RDS, OpenSearch, etc. we only support 1. I think we want to support 1 here as well.

[dlvenable]

I think we can do this in a follow on as well.

[srikanthpadakanti]

Agreed. Will implement PluginConfigVariable for bearer token in a follow-up PR to support secrets manager reads (form 1). Keeping this PR scoped to the Data Center connectivity feature.

Here's the follow up issue #6844 to track