feat(datahub-client): add java kafka emitter

[MugdhaHardikar-GSLab]

Checklist

• The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
• Links to related issues (if applicable)
• Tests for the changes have been added/updated (if applicable)
• Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
• For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

[github-actions]

Unit Test Results (build & test)

385 tests  +3   385 ✔️ +3   10m 7s ⏱️ +50s
  91 suites +2       0 💤 ±0 
  91 files   +2       0 ❌ ±0 

Results for commit 3d5e1d2. ± Comparison against base commit 0ee2569.

♻️ This comment has been updated with latest results.

[RyanHolstien]

This pins us to a particular model from the MetadataChangeProposal instead of using the generated one. Was there no other way to get the CI passing?

[MugdhaHardikar-GSLab]

This file is just placeholder. It will get replaced by latest avsc during jar build.

[ercsonusharma]

Is it intended not to have emit(List<UpsertAspectRequest> request, Callback callback) method for KafkaEmitter similar to the RestEmitter? Having that will make it compatible with existing codebase and need not to migrate to emit(MetadataChangeProposalWrapper mcpw, Callback callback) - Any thoughts?

[RyanHolstien]

Is it intended not to have emit(List<UpsertAspectRequest> request, Callback callback) method for KafkaEmitter similar to the RestEmitter? Having that will make it compatible with existing codebase and need not to migrate to emit(MetadataChangeProposalWrapper mcpw, Callback callback) - Any thoughts?

The UpsertAspectRequest object uses the OpenAPI compatible models rather than the Avro compatible models so I don't think it makes sense to support it. Would require converting back from the OpenAPI models to Avro.

[shirshanka]

small changes

[shirshanka]

LGTM