[Service Bus] ServiceBusMessage to expose all AMQP details

Motivation for this change:

A desire to allow reading and writing of the different parts of an AMQP message as described by the AMQP spec. This gives us the interopability feature when one uses a different client that does support writing to these parts, but then uses our libraries to read the message. See “Message Format” in section 3.2 of the AMQP spec

Guiding factors for the proposal:

• Existing users used to accessing either AMQP properties like messageId or AMQP message annotations like partitionKey or AMQP message header like deliveryCount should continue to have these as top level entities
• All inner details of AMQP message should be accessible to the advanced user. Since these do not matter to the most of the user segment, these details need not be at the top level. Therefore, we would like to hide the details (header, footer, message annotations, deliver annotations, properties) in a nested field. This model can be replicated in Event Hubs in the future
• We do not want to introduce any new AMQP message detail as a top level entity at this moment in time to avoid increasing the surface area and potential confusion due to introduction of new elements. If the service team determines that an AMQP message detail from header/footer/message annotations/delivery annotations deserves to get a spot on the top level, it should be do-able incrementally in a non breaking fashion

[bterlson]

I’m a fan of approach 2, personally. Although, since ReceivedMessage is a subtype of ServiceBusMessage, it would be nice if their names are related similarly. ReceivedServiceBusMessage seems pedantically correct but maybe too long. Open to other suggestions, or keeping the current names if no alternatives are palatable.

[HarshaNalluru]

Isn’t we discussed that there is always one variable/source for a property ‘value’ and that gets changed whether user change at top level or in amqpMessageDetails ? User can change a value at any level and it will update one source.

@hemanttanwar The problem is… we can’t stop a user from constructing a message object with two different "body"s in JS, which is not a problem in Java or .NET.