Need: Find a better way to be able to distinguish Kafka messages specific to a use case without having to parse all the Kafka messages.

Future multi-tenancy architecture should segregate services between each other (each BP processor will have its own topic) so there's no need to over design a solution right now 

Idea:

• Use the blueprint name as Kafka Key
  • Ex: instead of having “org.onap.ccsdk.cds.blueprintsprocessor.message.service.KafkaMessageProducerService@685e8e17” as a key, it would be the blueprint name
  • Could make sense for the audit service
• For request, they are sending the key in the request but don't get it in the response
  • Kafka key provided in the request should be sent back in the response

Main use case if for Kafka Listener for now. Story can be broken down if implementation is too risky

AC:

• For audit service, blueprint name is used as Kafka Key
• For Kafka listener response, send back the Kafka key provided in the request
• Even if not specified by the user in the request, a unique Kafka Key is still send back in the response