kgo: add TopicID to the FetchTopic type

[twmb]

Closes #790.

[arjunnair1997]

Nice, so if version >= 13, I should be assured that this is set?

[twmb]

It's set if the broker returns it -- it's a new field in fetch response v13, yes -- and this will be all 0s if it is unset.

[arjunnair1997]

Gotcha, I assume all 0s is an invalid topic id.

[arjunnair1997]

nit: maybe add fetch request version? Will make it easier for someone using the API, I think.

[twmb]

End users generally don't actually know what version of Kafka introduced what version of a request. It's undocumented anywhere -- a person has to first know the version a field was introduced in, then figure out which KIP introduced that version, then figure out which version of Kafka the KIP was actually released in.

Mentioning the version of Kafka that introduced topic IDs in the fetch response circumvents that process and gets directly to the answer, IMO.

[twmb]

Topics do not have all 0 topic IDs, if the cluster supports topic IDs. The user can be sure that a topic ID is present based on the fact it is not all 0s. I use this same comparison myself:

franz-go/pkg/kgo/metadata.go

Lines 795 to 803 in 6b61d17

	var noID [16]byte
	if newTP.cursor.topicID == noID && oldTP.cursor.topicID != noID {
	cl.cfg.logger.Log(LogLevelWarn, "metadata update is missing the topic ID when we previously had one, ignoring update",
	"topic", topic,
	"partition", part,
	)
	retryWhy.add(topic, int32(part), errMissingTopicID)
	continue
	}

franz-go/pkg/kgo/source.go

Lines 1895 to 1898 in 6b61d17

	var noID [16]byte
	if c.topicID == noID {
	f.disableIDs = true
	}