This pull-request adds support for receiving can frames with timestamps from the kernel.
It tries to solve issue#22. It shows, that the concept works. See the examples.
I chose to provide new socket types, which provide a tuple as a return type, whenread_frame'ing from the socket. This tuple contains aCanFrame and aOption<SystemTime>. While providing these Sockets requires a lot of boilerplate code for implementing the Traits, I think this way feels very natural from a socketcan-rs user perspective.
There are however some points I would like to discuss:

1. Is this way a valid aproach to provide timestamps? What do you think?
2. The return type with the tuple:(CanFrame, Option<SystemTime>) I got this from the TODO inside of src/socket.rs. Maybe it is better to provide a named struct here? Something likeCanFrameTimestamp that then contains theCanFrame and theSystemTime.
3. I was searching for a proper rust type to return the timestamp. The linux kernel hasstruct timespec on the C side. The nix crate hasTimeSpec for this, but I think returning a nix crate type here is maybe not the right thing? What do we have in std? Well, there isDuration,Instant andSystemTime. From these three,SystemTime felt the best, but I am not sure.
4. For now I did choose to return theSystemTime in anOption, because, well is there something that can go wrong while obtaining the timestamp? Maybe when we do not have acmsg? Can this fail? What to do, when this fails? I don't know. For now, this is an Option. Is this a good idea?
5. Please pay some attention to the not-very-rust-like unsafe block. I did this to cast theIoSliceMut, that I get fromrecvmsg into alibc::canframe without copying bytes around. Copying of the bytes does happen when constructing aCanFrame::from(libc_f) a little later. Is this a feasible way here? Can anybody come up with something better? Maybe something more idiomatic rust?
6. In the same unsafe block I useptr::from_ref which is not accepted by the current CI. I know this. This can also be done by another pointer-casting-dereference-dance, which looks very ugly. Maybe when anybody comes up with a better solution for 5., this can be eliminated along the way? If not, I would opt to raiserust-version and CI to 1.76 which bringsstd::ptr::from_ref out of nightly. I added a patch raising the rust-version as test. This can be removed if there are any objections.
7. Naming:CanSocketTimestamp andCanFdSocketTimestamp. Does this sound right?
8. I introduceopen_with_timestamp with an enumTimestampingMode, to choose between hardware and software timestamping. Any comments on this?open_addr is doingTimestampingMode::Software as a default. Is this sane?

I could only test software timestamps so far. I try to set up something to test hardware timestamps as well.