[INLONG-12215][Manager] Filter sensitive JDBC URL params in OceanBase sink

[akashchamp]

Fixes #12215

Motivation

OceanBaseSinkDTO#getFromRequest persists the submitted JDBC URL as-is,
even though its own @apiNote says sensitive params must be filtered
before saving:

/**
 * @apiNote The config here will be saved to the database, so filter sensitive params before saving.
 */
public static OceanBaseSinkDTO getFromRequest(OceanBaseSinkRequest request, String extParams) {
    OceanBaseSinkDTO dto = ...;
    CommonBeanUtils.copyProperties(request, dto, true);
    return dto;
}

The sibling MySQL sink DTO had exactly the same gap and was fixed in
#11732 (INLONG-11731) by calling MySQLSensitiveUrlUtils.filterSensitive(...)
on the URL before it is stored. That fix was never applied to the
OceanBase sink, so a tenant can still submit an OceanBase sink whose
JDBC URL carries autoDeserialize=true (and the other params
MySQLSensitiveUrlUtils neutralizes: allowLoadLocalInfile,
allowUrlInLocalInfile, allowLoadLocalInfileInPath). That raw URL is
stored, then forwarded verbatim by OceanBaseLoadNode.tableOptions()
to the Flink JDBC connector / Connector-J, where autoDeserialize=true
enables unsafe Java deserialization on ResultSet.getObject().

Note the OceanBase JDBC URL is already MySQL-protocol-compatible (the
class even defines OCEANBASE_JDBC_PREFIX_CDC = "jdbc:mysql://" for
the CDC path), so reusing MySQLSensitiveUrlUtils directly — the same
utility OceanBaseJdbcUtils (the Manager-side connectivity check) and
StarRocksDataNodeDTO already reuse — is consistent with the rest of
the codebase, not a new dependency.

Modifications

• OceanBaseSinkDTO#getFromRequest: filter request.getJdbcUrl()
  through MySQLSensitiveUrlUtils#filterSensitive before it is stored
  on the DTO, mirroring MySQLSinkDTO#getFromRequest.
• Add OceanBaseSinkDTO#filterSensitive(String), a thin wrapper around
  MySQLSensitiveUrlUtils#filterSensitive, mirroring the existing
  MySQLSinkDTO#filterSensitive(String) for consistency and testability.

No behavior changes outside the OceanBase sink's getFromRequest path.

Verifying this change

• This change added tests and can be verified as follows:
  • Added OceanBaseSinkDTOTest#testFilterSensitive, adapted from the
    existing MySQLSinkDTOTest#testFilterSensitive for OceanBase URLs
    (plain params, percent-encoded params, parenthesized param lists).
  • Added OceanBaseSinkDTOTest#testGetFromRequestFiltersSensitiveParams,
    a regression test asserting getFromRequest(...) on a request whose
    jdbcUrl contains autoDeserialize=true&allowLoadLocalInfile=true
    produces a DTO whose jdbcUrl no longer contains
    autoDeserialize=true (it is replaced with autoDeserialize=false,
    etc.).
  • Confirmed the bug first: with the OceanBaseSinkDTO fix
    reverted (test file kept), mvn test fails to compile the new
    test — cannot find symbol: method filterSensitive(String) —
    because the filtering method/call doesn't exist on main yet.
  • After the fix: ran
    mvn -pl inlong-manager/manager-pojo -am test
    (JDK 11, Maven 3.9.16) — full manager-pojo module suite:
    Tests run: 45, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS,
    including both new tests and the pre-existing
    MySQLSinkDTOTest#testFilterSensitive (unaffected, still passing).
  • Ran mvn spotless:check on manager-pojo: no violations.

Documentation

• Does this pull request introduce a new feature? no
• If yes, how is the feature documented? not applicable