KIP-320 implementation

[emasab]

Reopening with a different branch as CI only runs on feature branches

Remaining tasks:

• Write changelog to outline the new behaviour with epochs,
  and what it fixes.
  Also mention the new ERR__LOG_TRUNCATION error code that will
  be raised if log truncation is detected on the broker due to
  unclean leader election.

• Write test cases using the mock broker. This also requires
  the new OffsetForLeaderEpochRequest to be added to the mock handlers.

• Run the AK system tests truncation test suite to verify that the
  verifiable consumer (backed by librdkafka, preferably thru the python client)
  handles log truncation properly.
  Talk with Jing about running on Jenkins, and/or try to get it working
  with the local docker/ducker-ak based system testing.
  In the latter case you will need to find a way to get the verifiable clients
  on the docker images that are tested.

• For high-level language bindings the following changes are needed:

• Add the ERR__LOG_TRUNCATION error type.
• Make sure that any relevant uses of rd_kafka_topic_partition_list_t
  and rd_kafka_topic_partition_t now respects and retains the
  leader epoch: use get_leader_epoch() to retrieve and set_leader_epoch()
  to set. Relevant APIs are:
  • seek
  • seek_partitions
  • commit
  • committed
  • position
  • *assign()
  • message_leader_epoch()
• For .NET: add new method alternatives that takes the new TopicPartitionOffsetEpoch type.
• The message object now has a leader_epoch() method, for the consumer, for committing
  offsets outside of Kafka.

• The two convenience functions rd_kafka_buf_[write|read]_topic_partition_list()
  were changed to take an array of field specifiers, this allows these functions
  to be reused for various read/write partition array jobs even
  when the field ordering differs.
  However, the calling signature is variadic, which means existing code that calls
  these functions will compile but not work - this has been fixed in this PR
  of course, but other PRs sub-sequent to this one needs to be fixed too.

[milindl]

Finished a first pass review for all the main parts of KIP-320. Mostly, it looks good to me. Just a few questions in the comments, especially one with reference to KIP-392 interaction with KIP-320.

The mock and test changes aren't a part of the review (and I have not yet made minor/nit comments).

[milindl]

Approving it based on some internal discussion. I'll take a look once more but it seems fine to me.

Mainly, we discussed the comment about case3: the implementation in AK client is different from the KIP-392, and the same as here. I had made that comment based on the KIP. Things should be okay.
There are still some changes like log messages (minor) that @emasab is doing but those won't really block this PR from merging.