Expose MessageId as part of Record interface

[srkukarni]

<--

Contribution Checklist

• Name the pull request in the form "[Issue XYZ][component] Title of the pull request", where XYZ should be replaced by the actual issue number.
  Skip Issue XYZ if there is no associated github issue for this pull request.
  Skip component if you are unsure about which is the best component. E.g. [docs] Fix typo in produce method.

• Fill out the template below to describe the changes contributed by the pull request. That will give reviewers the context they need to do the review.

• Each pull request should address only one issue, not mix up code from multiple issues.

• Each commit in the pull request has a meaningful commit message

• Once all items of the checklist are addressed, remove the above text and this checklist, leaving only the filled out template below.

(The sections below can be removed for hotfixes of typos)
-->

(If this PR fixes a github issue, please add Fixes #<xyz>.)

Fixes #

(or if this PR is one task of a github issue, please add Master Issue: #<xyz> to link to the master issue.)

Master Issue: #

Motivation

Explain here the context, and why you're making that change. What is the problem you're trying to solve.

Modifications

Describe the modifications you've done.

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is a trivial rework / code cleanup without any test coverage.

(or)

This change is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end deployment with large payloads (10MB)
• Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If yes was chosen, please highlight the changes

• Dependencies (does it add or upgrade a dependency): (yes / no)
• The public API: (yes / no)
• The schema: (yes / no / don't know)
• The default values of configurations: (yes / no)
• The wire protocol: (yes / no)
• The rest endpoints: (yes / no)
• The admin cli options: (yes / no)
• Anything that affects deployment: (yes / no / don't know)

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)
• If a feature is not applicable for documentation, explain why?
• If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

[srkukarni]

run java8 tests

[srkukarni]

run java8 tests

[srkukarni]

run java8 tests

[srkukarni]

run java8 tests

[srkukarni]

run java8 tests

[srkukarni]

run java8 tests

[srkukarni]

run java8 tests

[srkukarni]

run java8 tests

[jerrypeng]

@srkukarni I thought we were going to do this

#4127

to expose on all the attributes of the underlying message

[srkukarni]

I'm not sure if there has been alignment wrt that pr.

[jerrypeng]

@srkukarni then lets get into agreement what we should do about this problem. I just don't want multiple ways to get the same information and cluttering the context API. We do need a simpler way to expose all the attributes of a Message so that we don't have to keep adding these one-off APIs to retrieve them. Today someone asks for MessageId, tomorrow someone might ask for getting the key of the message. I think we either allow users to consume Message as input or from the context API we can get the underlying message. I would be more in favor of the former, the one @sijie proposed

[sijie]

then lets get into agreement what we should do about this problem.

+1 I think we should get an agreement on what directions we are taking the API to.

[sijie]

Closed this pull request since #4341 already exposed message to record.