Having the definitions sit in the `net/gnrc/sixlowpan/frag.h` header
does not make much sense, when using Selective Fragment Forwarding
(and the fragmentation buffer already includes a
`net/gnrc/sixlowpan/frag/stats.h` header), so they are moved to their
own header. Since with this change it makes more sense to have the
statistics stored in their own sub-module, the pseudo-module is also
actualized.
`gnrc_sixlowpan_frag_rb_base_rm()` cleans up the intervals which is part
of `gnrc_sixlowpan_frag_rb`, not `gnrc_sixlowpan_frag`, so when the
`gnrc_sixlowpan_frag` is not compiled in, but `gnrc_sixlowpan_frag_rb`,
the intervals allocated in the reassembly buffer and inherited by the
virtual reassembly buffer are never released.
45f7966 made the `src_len` field the "emptiness signifier" for the VRB.
However, when `gnrc_sixlowpan_frag` is compiled in, the remove function
`gnrc_sixlowpan_frag_vrb_rm()` does not set the `src_len` to zero,
resulting in already deleted entry to be recognized as non-empty.
This allows to set a timer between the completion of a datagram in the
reassembly buffer and the deletion of the corresponding reassembly
buffer entry. This allows to ignore potentially late incoming link-layer
duplicates of fragments of the datagram that then will have the
reassembly buffer entry be blocked.
This was noted in this [discussion] for classic 6LoWPAN reassembly (and
minimal fragment forwarding) and is recommended in the current
[selective fragment recovery draft][SFR draft].
[discussion]: https://mailarchive.ietf.org/arch/msg/6lo/Ez0tzZDqawVn6AFhYzAFWUOtJns
[SFR draft]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-07#section-6
This imports the protocol parameters for Selective Fragment Recovery
(SFR). For the values I took some educated guesses based on my
experience with previous experimentation with fragment forwarding.
The defines currently are based on [draft v7].
[draft v7]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-07#section-7.1
fixup! gnrc_sixlowpan_frag: initial import of SRF parameters
The name `fragment_msg` or `frag_msg`/`msg_frag` always to me was a bit
misplaced, as it basically implements an asynchronous fragmentation
buffer and doesn't necessarily have anything to do with messages.
This change
1. changes the name to `fb` (for fragmentation buffer)
2. factors its code out to its own sub-module so it can be re-used by
other 6LoWPAN fragmentation schemes like [Selective Fragment
Recovery]
[Selective Fragment Recovery]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-05
Rather than dispatching the packet automatically once it is complete,
`gnrc_sixlowpan_frag_rb_add()` now only returns success, and leaves it
to the caller to dispatch the packet.
