Finish implementing LL connections

[jonas-schievink]

Current status: Connections are established, channel hopping works, we can exchange PDUs.

What needs to be done:

• [ ] Test that exchanging more than 1 pair of PDUs per connection event works
• [x] Add timeout when listening for a connection event (currently it hangs indefinitely as soon as a single PDU in a connection event fails to arrive)
  • The timeout should fire after the transmit window ends. When it fires, hop to the next channel and listen there.
• [x] Make the other side actually receive the packets we send (probably T_IFS isn't upheld)
• [x] LL Control PDUs need to be parsed and answered (for now, with LL_UNKNOWN_RSP)
• [x] Need to figure out how the sequence numbers in the first PDU are supposed to be handled
  • The LinkLayer starts with both set to 0 because the spec says so
  • The first PDU we receive also has both SN and NESN set to 0, which, according to the spec, means that we should retransmit the last PDU. However, there is no last PDU at this point, so this doesn't make sense.
• [x] Fix connections with iOS devices

(there's more stuff missing that we'll implement later, like the supervision timeout)

[jonas-schievink]

The recent changes that made it work with my Android phone somehow broke it for iOS, so that's also something that needs to be investigated. I don't have any iOS devices though, so @chocol4te probably needs to help with this.

How annoyingly expected...

EDIT: For the record, this is the trace when connecting to an iPhone:

7.405726s - DATA->Header { LLID: DataCont, NESN: 1, SN: 0, MD: false, Length: 0 }
7.419197s - DATA(14->14)<- Header { LLID: DataCont, NESN: 0, SN: 0, MD: true, Length: 0 }, []
7.419750s - DATA(14->4): missed conn event
7.450397s - DATA(4->5): missed conn event
7.481034s - DATA(5->19): missed conn event

This means that we're not even receiving the packets the phone is sending anymore, which is worse than the starting point with Android (where we could receive packets, but the phone didn't correctly receive ours).

[jonas-schievink]

d229197 makes us ignore MD bits instead of wrongly trying to respect them, which makes connections work on iOS and with my desktop (which is using a USB dongle).

One nRF52 we have still refuses to show up on iOS, presumably due to bad T_IFS handling for scan or connect requests. We'll fix that one later though.