This change handles the final part of KIP-881: triggering a rejoin, in case we detect that one of the topics we are subscribed to, has a change in the set of racks of one of its partitions.
More precisely,
trigger a rejoin, if

1. client.rack is set for consumer
2. there exists a partition P of a topic T, such that we are subscribed to T and racks_in_cached_metadata(P) != racks_in_fresh_metadata(P).

As for the implementation details:

1. rd_kafka_metadata_partition_internal_t now contain an racks and their count.
2. rd_kafka_topic_info_t now contains a list of rd_kafka_metadata_partition_internal_t*
3. Constructors for (2) have been modified for the changes.

For non-regex case (where we look up the topic information from the topic metadata cache), the topic metadata cache entry is internally, using rd_kafka_metadata_topic_internal_t. We just populate the racks inside the rd_kafka_metadata_partition_internal_t from the broker/rack mapping.
This operation allocates strings, since there's no linkage of the lifetime between the cache entry and the broker/rack mapping.

For the regex case (where we look up the topic information from the full cache), we use the rd_kafka_metadata_partition_internal_t inside the full cache. We just populate the racks inside the rd_kafka_metadata_partition_internal_t from the broker/rack mapping. However, since the full cache also contains the broker/rack mapping, we don't allocate extra space for the string, just point inside the broker/rack mapping.

All the allocation/deduplication/sorting costs are only paid if the client rack is set. And when the replica racks are set. Otherwise, it's avoided.

A test is also added, and some fixes/changes to the mock broker to facilitate that.