Don't lock the allocator with spin.

[gendx]

This change uses the heap of linked_list_allocator directly instead of locking it via a mutex. Since the app is single threaded this shouldn't be a problem.

This also allows to remove the spin dependency of linked_list_allocator, which isn't maintained anymore since RUSTSEC-2019-0031, thereby addressing one half of #24.

After this change, cargo audit should only mention spin via the ring dev-dependency.

• Tests pass
• Appropriate changes to README are included in PR

[ia0]

I don't think #24 is an issue that should trigger code changes on our side. The fact that a crate is not maintained since a few months is not a short-term issue.

Do we believe adding one more patch to maintain is worth it?

[gendx]

Although there's no urgency, I think keeping a clean cargo audit is worth it in the long term for better code hygiene.

As for the additional maintenance, it's indeed an extra patch, but not that many more lines of code and also following what was done upstream in tock/libtock-rs#107. If it ever turns out to be an issue, we can also coordinate that with upstream libtock-rs.

[ia0]

I agree having a clean cargo audit is good, but it's just a tool and its output has to be interpreted. In that case, I think the output can be dismissed.

However since this patch reduces the diff with upstream, it might make the merging easier if that merging doesn't happen too far in the future.

[gendx]

I agree having a clean cargo audit is good, but it's just a tool and its output has to be interpreted. In that case, I think the output can be dismissed.

Since we chose to integrate this tool in our CI, I don't think it makes sense to dismiss the output when we can reasonably fix it.