NFD

The design needs to be reviewed before starting implementation.
The initial design reviews will be conducted internally at Arizona.

Hints for design:

• LinkService-face.hpp "generic LinkService" section, comments after external API
• LinkService_20150828.pptx "generic link service" section, send path and receive path
• NDNLPv1 fragmentation and reassembly implementation in NFD

The design needs to answer the following questions:

• What's the send path and receive path?
  With only the features listed in issue description, it would be simpler than LinkService_20150828.pptx.
• How to process fragmentation and reassembly when GenericLinkService is working with a multi-access underlying link?
  Hint: reassemble packets from each source address separately
• Show the public API for classes used in fragmentation and reassembly (as a header).
• Show the full API for GenericLinkService (as a header).

Implementation of fragmentation and reassembly building blocks is split into #3171 so that it's individually assignable.

The boundary of fragmentation and reassembly building blocks is:

• Given an unfragmented packet, MTU, and an estimated header size (for NACK, etc), the fragmentation building block can slice the packet into multiple LpPackets.
  This is similar to nfd::ndnlp::Slicer in NDNLPv1 implementation, except that sequence numbers are not assigned.
• Given received packets from a single source, the reassembly building block can reassemble packets.
  This is similar to nfd::ndnlp::PartialMessageStore in NDNLPv1 implementation.

#3104 should decide the exact API to be provided by #3171.

When working with a multi-access transport, #3104 should find a way to arrange multiple reassembler instances, one for each remote sender.

"higher priority" part described in note-6 is not blocked by #3179, and can start as soon as #3088 is complete.

Documentation requirement is moved to #3173.

I'm updating this issue to include only packet encoding/decoding.

Fragmentation and reassembly are split to #3171.