fix: set retention.ms to -1 instead of Long.MAX_VALUE

[agavra]

Description

There may be a bug with Kafka's handling of Long.MAX_VALUE as a topic retention. This PR is defensive in setting it to the documented value for infinite retention: -1

Testing done

Unit testing, and spun up a new ksql server:

Topic: _confluent-ksql-default__command_topic	PartitionCount: 1	ReplicationFactor: 1	Configs: min.insync.replicas=1,cleanup.policy=delete,segment.bytes=1073741824,retention.ms=-1,unclean.leader.election.enable=false

Reviewer checklist

• Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
• Ensure relevant issues are linked (description should include text like "Fixes #")

[apurvam]

can you verify the behavior for when you have this patch and restart the server with a non -1 value? Say the old LONG_MAX? Does it switch to -1?

[agavra]

At t=0 spun it up with 0.9.0:

Topic: _confluent-ksql-default__command_topic	PartitionCount: 1	ReplicationFactor: 1	Configs: min.insync.replicas=1,cleanup.policy=delete,segment.bytes=1073741824,retention.ms=9223372036854775807,unclean.leader.election.enable=false

Tore down ksql and spun up my custom one:

Topic: _confluent-ksql-default__command_topic	PartitionCount: 1	ReplicationFactor: 1	Configs: min.insync.replicas=1,cleanup.policy=delete,segment.bytes=1073741824,retention.ms=-1,unclean.leader.election.enable=false
	Topic: _confluent-ksql-default__command_topic	Partition: 0	Leader: 1	Replicas: 1	Isr: 1

[rodesai]

LGTM