Prepare release 0.9.1

[sosthene-nitrokey]

I think these should be merged first

• Make LenType opt-in #569
• De-monomorphize spsc consumer and producer #571
• Remove generic from history_buf::OldestOrdered #570

[therealprof]

@sosthene-nitrokey I don't think we should block this on #571 and just get it merged.

[sosthene-nitrokey]

#571 is not a "blocker" but I'd rather do the breaking change before releasing (especially given that the PR has been reviewed and is only one nitpick being resolved away from being merged) rather than #571 ending up being blocked forever on a new breaking release to be merged.

I reworded the pr description to remove the "blocked on", if you judge #571 should be ignored.

[therealprof]

I'd put it the other way around. People are eagerly waiting for a release and #571 is standing in the way of the release. We don't have any limit on the number of releases we can cut, so to me it doesn't make much sense to wait until #571 is ready.

[sosthene-nitrokey]

That makes sense to me. On the other hand I personally find it a bit frustrating that I initially made the View PRs in a way that they would be backwards compatible for a 0.8.1 release, and documented the breaking changes I wanted to do in #494 for a next release, but 0.8.1 was never released, and when it was decided to go for 0.9.0 the desired breaking changes were ignored.

I don't say that to justify that my PR should be merged, but to explain why I wanted those breaking changes included before the next release. I understand that maintainer bandwidth can be scarce so it makes sense to not prioritize small ergonomic improvements over releasing what's already there, so if you want to release 0.9.0 as-is it's fine by me.