hfsplus: add KUnit coverage for canonical reordering and legacy fixups

Add regression tests for checking that decomposed catalog names
get canonically reordered and legacy-decomposition corrected
before storage, matching what macOS's own fsck_hfs requires and
previously flagged as "Illegal name" (reproducible via xfstests
generic/339).

Two small helpers, test_char2uni_utf8()/test_uni2char_utf8(), wrap the
real utf8_to_utf32()/utf32_to_utf8() codec: the existing
test_char2uni()/test_uni2char() stand-ins only handle one raw byte per
character and can't represent the multi-byte combining marks (U+0301,
U+0323, ...) these tests need.

New cases:

 - hfsplus_asc2uni_combining_reorder_test: two independently-typed
   combining marks (U+0301 class 230, U+0323 class 220) end up stored
   in ascending combining-class order regardless of typed order, are
   left alone when already canonical, and keep their relative order
   when their classes are equal (the sort must be stable).
 - hfsplus_unicode_combining_reorder_roundtrip_test: a name stored with
   marks reordered still reads back as the same, valid UTF-8.
 - hfsplus_asc2uni_legacy_decomp_test: U+01F8 decomposes to "N" +
   U+0300 even though Apple Technote #1150's table has no entry for it.
 - hfsplus_asc2uni_legacy_seq_fixup_test: a Greek letter + U+030D
   becomes that letter + U+0301, and Bengali BA + NUKTA collapses to
   the single letter RA WITH MIDDLE DIAGONAL.
 - hfsplus_hash_dentry_combining_reorder_test: two names differing only
   in typed mark order hash identically, since both canonicalize to the
   same stored form.
 - hfsplus_compare_dentry_combining_reorder_test and
   hfsplus_compare_dentry_legacy_decomp_test: likewise, both compare
   equal - a precomposed U+01F8 and its already-decomposed "N" + U+0300
   spelling must be found as the same catalog entry.

All 34 cases in the hfsplus_unicode KUnit suite (27 existing + 7 new)
pass under tools/testing/kunit/kunit.py.

Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
Link: https://lore.kernel.org/r/20260919001607.2777138-4-slava@dubeyko.com
Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>

0 files changed, 0 insertions, 0 deletions