Consider updating bitflags to v2 for the breaking 0.7 release

[w-flo]

• I have looked for existing issues (including closed) about this

Feature Request

Motivation

Bitflags released crate version 2 in March, introducing changes for types created with the bitflags! macro like axum's EventFlags.

The linked release notes contain some instructions what needs to be done to "undo" some of the breaking changes on bitflags!-created types, but it's not clear to me if these changes are enough to make the type fully backwards compatible, or if it's always a breaking change to update to bitflags v2.

Since a breaking 0.7 axum release is apparently planned, it may be worth considering to upgrade the bitflags crate to v2 in axum before cutting the release, as it will be more difficult (or impossible?) to upgrade bitflags while avoiding a breaking change.

Proposal

Consider upgrading bitflags to v2 before releasing axum 0.7.

Some of the things mentioned in the v2 release notes could be applied if they make sense for axum or axum users, like maybe deriving a few things that were derived automatically in bitflags v1.

Alternatives

Since v1 of the bitflags crate works fine and is not exactly heavy on build times, it could simply stay for the foreseeable future. I'll note that tower-http already depends on bitflags v2, so axum-extra currently pulls in bitflags v2.

[rsdlt]

Hi everyone, I've been using axum for some weeks and really like the project. I would like to tackle this as my first contribution if that's ok with you.

[davidpdrsn]

@rsdlt please do!