btrfs: prepare and move async csum generation out of experimental feautres

[CHANGELOG]
v2:
- Introduce a patch to fix a potential data loss with async direct writes
This is an existing bug, not only affecting the async data csum generation. Introduce a dedicated fix for it.

- Introduce a patch to fixx an ASSERT() false alert race Again an existing bug.

Sashiko exposed several problems related to previous default async csum generation, one fix related to encoded writes is already merged.

The remaining problems are:

- Possible data loss due to fast fsync with async direct writes Fixed by the first patch, not only affecting async csum generation. Although async csum generation will make it more obvious.

- A possible ASSERT() race which can trigger false alert Fixed by the second patch, by moving the ASSERT() out of the workqueue workload.

- Potential workqueue flush problems related to endio_workers Fixed by the 3rd patch, also as a preparation for the incoming default async data csum generation.

Then we can finally enable async data csum generation by default to improve the data write performance, and completely get rid of the old csum offloading behavior.

Qu Wenruo (4):
btrfs: do not allow fast fsync if there is any async dio write
btrfs: fix an ASSERT() race with async csum generation
btrfs: make btrfs_fs_info::workers to be a regular workqueue
btrfs: move async data csum generation out of experimental features

 fs/btrfs/Kconfig     |   2 -
 fs/btrfs/bio.c       | 139 +------------------------------------------
 fs/btrfs/direct-io.c |  11 ++++
 fs/btrfs/disk-io.c   |  47 ++++++---------
 fs/btrfs/file-item.c |  15 ++---
 fs/btrfs/file-item.h |   2 +-
 fs/btrfs/fs.h        |  17 +-----
 fs/btrfs/super.c     |   2 +-
 8 files changed, 43 insertions(+), 192 deletions(-)

2.56.0