MINOR: Use LogConfig.validate instead of validateValues in KafkaMetadataLog

[ijuma]

LogConfig.validateValues may fail or incorrectly succeed if the properties don't include defaults.

During the conversion of LogConfig to Java (#13049), it became clear that the asInstanceOf[Long]
calls in LogConfig.validateValues were converting null to 0 when this method was invoked
from KafkaMetadataLog. This means that it would be possible for it to validate successfully
in cases where it should not.

Committer Checklist (excluded from commit message)

• Verify design and implementation
• Verify test coverage and CI build status
• Verify documentation (including upgrade notes)

[jsancio]

LGTM. Thanks for the fix. I think we never saw an issue because KRaft was not using any of the properties validated in LogConfig.validateValues.

[ijuma]

@jsancio Yes, right - this preempts a potential issue if KRaft starts using some of the other properties. This fix also means we don't need to add a workaround in the PR that moves LogConfig to Java (an NPE happens without a workaround since the semantics of unboxing are different for Java).

[ijuma]

JDK 17 build passed, the other failures are unrelated:

Build / JDK 11 and Scala 2.13 / kafka.server.DynamicBrokerReconfigurationTest.testTrustStoreAlter(String).quorum=kraft
Build / JDK 8 and Scala 2.12 / org.apache.kafka.connect.mirror.integration.MirrorConnectorsIntegrationSSLTest.testReplicationWithEmptyPartition()
Build / JDK 8 and Scala 2.12 / org.apache.kafka.streams.integration.EosIntegrationTest.shouldWriteLatestOffsetsToCheckpointOnShutdown[exactly_once]