The use of this type has several drawbacks:
* It does not allow distinguishing between different error
conditions. In fact, we wrongly conflated some of them
before this commit.
* It does not allow propagation via ? and requires manual use
of map_err, which is especially tiresome for downstream code.
* It prevents us from expanding the set of error conditions
even if right now we have only one.
* It prevents us from blanket using Result<T> everywhere
(a nitpick at most).
Instead, use Result<T, Error> everywhere, and differentiate error
conditions where applicable.
Various parts of smoltcp require an arrow of time; a monotonically
increasing timestamp. Most obviously this is TCP sockets, but
the tracer and the pcap writer devices also benefit from having
timestamps. There are a few ways this could be implemented:
1. using a static Cell, global for the entire smoltcp crate;
2. using a static method on Device;
3. using an instance method on Device;
4. passing the current timestamp into *Interface::poll.
The first two options are undesirable because they create a notion
of global clock, and interfere e.g. with mocking.
The third option is undesirable because not all devices are
inherently tied to a particular clock, e.g. a loopback device isn't.
Therefore, the timestamp is injected into both sockets and devices
through the *Interface::poll method.
The changes in this commit affect the following scenario:
* Remote end sends octets 1..2, they are delivered and buffered
on local end;
* Remote end sends octets 3..4, they are lost;
* Remote end sends octets 5..6, they are delivered but cannot
be buffered on local end because we don't perform reassembly.
Before this commit, we would silently drop the segment with octets
5..6, relying on retransmission timer on the remote end. This works,
but can result in severe decrease in throughput. After this commit,
we send a duplicate ACK, which may trigger fast retransmit, if
implemented by the congestion control algorithm on the remote end.
whitequark