Re: mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address

["Gix, Brian" <brian.gix@intel.com>]

On Fri, 2019-09-27 at 10:52 +0200, michal.lowas-rzechonek@silvair.com wrote:
> Inga, Brian,
> 
> Still, even if we add a method, the application is free *not* to
> implement it, since we agreed back in the day that calls to
> MessageReceived do not require a response, so any errors would be simply
> ignored by the daemon.

This is not an option.

A node does not get to decide which susbscriptions are "valid".  If a Virtual Address subscription is added to
a node, and then a message is sent to that virtua address, the App needs to be able to receive it.

Yes, any discrete message may be lost, but I don't think we have the option of letting *all* virtual addressed
messages to an App to be ignored.  If we add an App API, it will need to be mandatory, which is why I am
against it.

I strongly believe we need:

1. A single method for delivering (non dev key) received messages
2. A method that does not require dictionary parsing

How are we feeling about:
	void MessageReceived(uint16 source, uint16 key_index,
				array{byte} destination, array{byte} data)


Where destination length of:
	0 - Unicast address of element
	2 - Group Address
	16 - Variable Label

I think this fulfills all of our requirements.