Linux 6.12 compat: Rename range_tree_* to zfs_range_tree_*

[IvanVolosyuk]

Linux 6.12 has conflicting range_tree_{find,destroy,clear} symbols.

Motivation and Context

Linux 6.12 introduced conflicting symbols which cause issues when compiling zfs with --enable-linux-builtin
See #16932 for context.
The change fix compilation in this configuration.

Description

The change is basically:
find . -type f -exec sed -i 's/range_tree_/zfs_range_tree_/g' {} +
... and manually fixing lines > 80 characters to get checkstyle pass.

How Has This Been Tested?

No functional changes, linux kernel 6.12 with ZFS builtin compiled successfully.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[amotin]

This is incredibly invasive change. Wish there was some easier one, but whatever. Just a couple thoughts:

• I would not rename metaslab_calculate_range_tree_type();
• You are renaming some things in range_tree.h, but not others. Sure I don't want even more changes, just the logic looks inconsistent.

[IvanVolosyuk]

Yeah, the change was pretty mechanical, I literally ran:
find . -type f -exec sed -i 's/range_tree_/zfs_range_tree_/g' {} +

What did I miss in range_tree.h? I can definitely revert change to metaslab_calculate_range_tree_type.
What about range_tree_t, I can keep it as it is - types cannot conflict with kernel symbols and it will remove a lot of churn.

[behlendorf]

What about range_tree_t, I can keep it as it is - types cannot conflict with kernel symbols and it will remove a lot of churn.

It's unfortunate it's so invasive, but if we're going to have to make this change let's be consistent about it and use zfs_range_tree_t. We had to do the same thing for zfs_btree_t.

[IvanVolosyuk]

I reverted renaming of metaslab_calculate_range_tree_type(), which was changed by mistake.
If I understand @amotin correctly for consistency we want to rename rs_*, range_seg*, RANGE_SEG*. I did that in a separate commit for now. Let me know if I should squash it into the main one.

[IvanVolosyuk]

Alternative to this change would be adding following lines to range_tree.h:

#define range_tree_find zfs_range_tree_find
#define range_tree_find_in zfs_range_tree_find_in
#define range_tree_create zfs_range_tree_create
#define range_tree_destroy zfs_range_tree_destroy
#define range_tree_clear zfs_range_tree_clear

May be also add #ifdef guard, so that the renaming only happening in cases when zfs is compiled in into the kernel. It is kinda hacky way and will make stack traces strange for the bug reports coming from people with zfs compiled into the kernel.