Add async API for CAN

[liamkinne]

Adds a new CAN trait with both async and fallback non-blocking methods.

Module is named asynch to avoid a collision with the async keyword. Alternatively a separate crate embedded-can-async could be published.

[burrbull]

Strange signature.

[liamkinne]

Inspired by a pattern I've seen around like here: https://docs.rs/rtic-sync/latest/rtic_sync/arbiter/struct.Arbiter.html

Can just get rid of it, but I think it's useful.

[adamgreig]

Thanks for the PR! We had a brief discussion about it in the weekly meeting today. Having the trait in the asynch module is fine. I think the only remaining question is whether to keep the try_x() methods, move to to another trait, or delete them entirely.

It looks like either the crate's MSRV (and related CI tests) will need updating, or the trait needs to be gated, to get CI passing, too.

[liamkinne]

@adamgreig thanks for the update.

I'm still strongly for keeping the try methods. The use case is that when libraries (bxcan, fdcan, etc) implement these traits they can only implement one trait at a time so they will have a blocking client and an async client. If you're using the async client but need to do something in a non-async context (think RTIC hardware task) you need something to fallback to that doesn't require .await.

It is very similar to the ideas around nb but more like "hey this method will work first time most of the time, unless your buffer is full which you can chose how to handle".

[liamkinne]

@adamgreig in the interest of getting this through so it can start being used downstream, I've removed the try methods.

[adamgreig]

Thanks for the prompt and the update. I'll add this to the agenda for discussion in the weekly meeting this Tues.

[Dirbaio]

these cfg_attrs do nothing without this in build.rs.

These were for compat with older nightlies before AFIT was stable. Now that AFIT has been stable for a few rust versions since 1.75, i'd just not put them, and support stable 1.75+ only.