[FLINK-27661][Runtime / Metrics] PrometheusPushGatewayReporter support pushgateway http authentication

[Myracle]

What is the purpose of the change

This pull request adds HTTP Basic Authentication support for the PrometheusPushGatewayReporter. This enables users to connect Flink metrics reporting to secured PushGateway instances that require authentication.

Many production deployments secure their PushGateway endpoints with authentication to prevent unauthorized metrics submission. Without this feature, users would need to configure network-level security (firewalls, VPNs) to protect the PushGateway, which is often more complex and less flexible than application-level authentication.

Brief change log

• Added username and password configuration options to PrometheusPushGatewayReporterOptions for specifying HTTP Basic Auth credentials
• Updated PrometheusPushGatewayReporter to configure BasicAuthHttpConnectionFactory when both credentials are provided
• Updated PrometheusPushGatewayReporterFactory to read credentials from configuration and emit a warning log when only one of username/password is configured (incomplete configuration)
• Added unit tests to cover all authentication scenarios (no auth, partial auth with warning, complete auth)
• Updated documentation (both English and Chinese) with configuration examples and security recommendations

Verifying this change

This change added tests and can be verified as follows:

• Added PrometheusPushGatewayReporterTest#testBasicAuthNotEnabledWithoutCredentials - verifies reporter creation without credentials
• Added PrometheusPushGatewayReporterTest#testBasicAuthNotEnabledWithOnlyUsername - verifies warning log when only username is configured
• Added PrometheusPushGatewayReporterTest#testBasicAuthNotEnabledWithOnlyPassword - verifies warning log when only password is configured
• Added PrometheusPushGatewayReporterTest#testBasicAuthEnabledWithBothCredentials - verifies reporter creation with complete credentials

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no (uses existing simpleclient_pushgateway dependency which already includes BasicAuthHttpConnectionFactory)
• The public API, i.e., is any changed class annotated with @Public(Evolving): yes (added new configuration options username and password to PrometheusPushGatewayReporterOptions which is annotated with @PublicEvolving)
• The serializers: no
• The runtime per-record code paths (performance sensitive): no
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? yes
• If yes, how is the feature documented? docs (updated docs/content/docs/deployment/metric_reporters.md and docs/content.zh/docs/deployment/metric_reporters.md)

[flinkbot]

CI report:

• aa9a53d Azure: FAILURE

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[rionmonster]

Minor consistency nit: for consistency, we may want to use defaultValue() instead of null here as those would both functionally identical (null) but would follow the same pattern as the other available configuration options.

For example, HOST_URL:

String hostUrl = metricConfig.getString(HOST_URL.key(), HOST_URL.defaultValue());

[Myracle]

Thanks for catching this! You're absolutely right - I've updated the code to use USERNAME.defaultValue() and PASSWORD.defaultValue() instead of hardcoded null to maintain consistency with other configuration options like HOST_URL.

[rionmonster]

I think we need to add another assertion to this test to verify that authentication was actually enabled. We may want to consider following a pattern similar to hostUrl to expose it for testing (e.g. @VisibleForTesting package-private boolean field), something like basicAuthEnabled and then we could simply check that property here:

assertThat(reporter.basicAuthEnabled).isTrue();

Either that or rely on a reflection based approach to inspect the underlying connection factory.

[Myracle]

Thanks for the suggestion! I've added a @VisibleForTesting boolean basicAuthEnabled field following the same pattern as hostUrl. Now all four basic auth test cases verify this property:
testBasicAuthNotEnabledWithoutCredentials - asserts basicAuthEnabled is false
testBasicAuthNotEnabledWithOnlyUsername - asserts basicAuthEnabled is false
testBasicAuthNotEnabledWithOnlyPassword - asserts basicAuthEnabled is false
testBasicAuthEnabledWithBothCredentials - asserts basicAuthEnabled is true

[rionmonster]

Minor nit: this can probably align with the recently added basicAuthEnabled flag to avoid the redundant logic.