shell: fix multicast pings

[OlegHahm]

This PR introduces two things in order to fix pinging of multicast addresses (or more general: to be able to handle additional ICMPv6 echo replies):

• adds a message queue to the main thread for the gnrc_networking example
• checks for pending additional packets delivered to the ping shell handler after unregistering

[miri64]

You are aware, that this is not correct, since the packets you receive before are also duplicates

[OlegHahm]

Yes, but there's no way to distinguish without a lot of added memory/complexity.

[OlegHahm]

I'm wondering if we shouldn't make it even mandatory for a thread registering at gnrc to have a message queue. What do you think?

[OlegHahm]

Added the queue also for the border router example, added a comment to explain the necessity, reduced the queue size, and made the error message for superfluous pongs more accurate.

[miri64]

I'm wondering if we shouldn't make it even mandatory for a thread registering at gnrc to have a message queue. What do you think?

I remember that I tried to include an assert() for that sometime in the past, but someone (I really can't remember) was against it.

[OlegHahm]

Let's discuss #4010 after the release.

[OlegHahm]

I just figured out that only the combination of this PR and #4006 will fix the issue completely.

[miri64]

Kind off was expecting something like that. How big is the packet loss with #4006?

[OlegHahm]

On native more or less 0.

[OlegHahm]

However the packetbuffer is not empty.

[OlegHahm]

The fragments in the packetbuffer look weird to me:

packet buffer: first byte: 0x8088fc0, last byte: 0x808a7c0 (size: 6144)
~ unused: 0x8088fc0 (next: 0x80893f0, size: 1056) ~
================ chunk   0 (size:   16) ================
000000 86 dd 00 00 08 00 00 00 e0 10 4d cf 00 00 00 00
~ unused: 0x80893f0 (next: 0x8089490, size:  152) ~
================ chunk   1 (size:    8) ================
000000 08 00 00 00 08 00 00 00
~ unused: 0x8089490 (next: (nil), size: 4912) ~

[OlegHahm]

However, I'm not able to create a fragmented packet buffer on iotlabs.

[OlegHahm]

I think the changes in this PR are sane anyway. If you don't disagree, how about getting this merged quickly?

[OlegHahm]

Tests for Specs 02 to 06 succeed with #4006 and this PR.

[miri64]

True the packet buffer looks really weird, since it looks like abandoned data... Otherwise, this change is a step in the right direction so ACK (is there a release version for it)?

[OlegHahm]

Yes, see #4009.

[OlegHahm]

squashed