Fix wrong semantics and usage of KafkaTopicManager#getTopic

[BewareMyPower]

Motivation

Many usages of KafkaTopicManager#getTopic are wrong because they didn't check null value so that NPE may happen. And the semantics of KafkaTopicManager#getTopic is wrong because the createIfMissing argument of BrokerService#getTopic is true, so if a not existed topic's name was accepted as the argument, the topic would be created automatically. This behavior is unexpected because we only want to create topics automatically in METADATA request handler.

Modifications

1. In KafkaTopicManager#getTopic, when BrokerService#getTopic is completed exceptionally, returns an exceptionally completed future instead of a null completed future.
2. Use whenComplete for all getTopic references so that we can handle null completed futures and exceptionally completed futures.
3. The LIST_OFFSET request handler is modified according to the above changes
   • For exceptionally completed getTopic future, return the thrown exception.
   • For null completed getTopic future, return the UNKNOWN_TOPIC_OR_PARTITION error.
4. Add tests for listing offsets of a not existed topic. Since the default ctx of KafkaRequestHandler is null and may cause NPE during error logging, we also set a mocked ChannelHandlerContext in the test.
5. Remove redundant NPE warning logs in MessageFetchContext#handleFetch since we've already added logs to the case that the future of KafkaTopicConsumerManager is completed exceptionally.

[BewareMyPower]

There're some failing tests that need to be fixed:

Error:    KafkaTopicConsumerManagerTest.testGetTopicConsumerManager:115 expected [true] but found [false]
Error:    KafkaTopicConsumerManagerTest.testTopicConsumerManagerRemoveAndAdd:145 NullPointer

[BewareMyPower]

@jiazhai now this PR is ready for review, PTAL.