Fix: btrfs_chunk tracepoints changed in linux 6.8.0-rc1

Fix: btrfs_chunk tracepoints changed in linux 6.8.0-rc1

See upstream commit:

    commit 7dc66abb5a47778d7db327783a0ba172b8cff0b5
    Author: Filipe Manana <fdmanana@suse.com>
    Date:   Tue Nov 21 13:38:38 2023 +0000

        btrfs: use a dedicated data structure for chunk maps

        Currently we abuse the extent_map structure for two purposes:

        1) To actually represent extents for inodes;
        2) To represent chunk mappings.

        This is odd and has several disadvantages:

        1) To create a chunk map, we need to do two memory allocations: one for
           an extent_map structure and another one for a map_lookup structure, so
           more potential for an allocation failure and more complicated code to
           manage and link two structures;

        2) For a chunk map we actually only use 3 fields (24 bytes) of the
           respective extent map structure: the 'start' field to have the logical
           start address of the chunk, the 'len' field to have the chunk's size,
           and the 'orig_block_len' field to contain the chunk's stripe size.

           Besides wasting a memory, it's also odd and not intuitive at all to
           have the stripe size in a field named 'orig_block_len'.

           We are also using 'block_len' of the extent_map structure to contain
           the chunk size, so we have 2 fields for the same value, 'len' and
           'block_len', which is pointless;

        3) When an extent map is associated to a chunk mapping, we set the bit
           EXTENT_FLAG_FS_MAPPING on its flags and then make its member named
           'map_lookup' point to the associated map_lookup structure. This means
           that for an extent map associated to an inode extent, we are not using
           this 'map_lookup' pointer, so wasting 8 bytes (on a 64 bits platform);

        4) Extent maps associated to a chunk mapping are never merged or split so
           it's pointless to use the existing extent map infrastructure.

        So add a dedicated data structure named 'btrfs_chunk_map' to represent
        chunk mappings, this is basically the existing map_lookup structure with
        some extra fields:

        1) 'start' to contain the chunk logical address;
        2) 'chunk_len' to contain the chunk's length;
        3) 'stripe_size' for the stripe size;
        4) 'rb_node' for insertion into a rb tree;
        5) 'refs' for reference counting.

        This way we do a single memory allocation for chunk mappings and we don't
        waste memory for them with unused/unnecessary fields from an extent_map.

        We also save 8 bytes from the extent_map structure by removing the
        'map_lookup' pointer, so the size of struct extent_map is reduced from
        144 bytes down to 136 bytes, and we can now have 30 extents map per 4K
        page instead of 28.

Change-Id: Ie52b5ac83df4bc6abeb84d958c4f5d24ae0d8c75
Signed-off-by: Kienan Stewart <kstewart@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>