None of the above!
Whatever we're calling this function *it does not belong* in mm.h.
Anything outside the MM calling it is going to be a disaster -- can you
imagine what will happen if a filesystem or device driver is handed a
folio and decides "Oh, I'll just change the size of this folio"? It is
an attractive nuisance and should be confined to mm/internal.h *at best*.
Equally, we *must not have* separate folio_set_order() and
folio_set_nr_pages(). These are the same thing! They must be kept
in sync! If we are to have a folio_set_order() instead of open-coding
it, then it should also update nr_pages.
So, given that this is now an internal-to-mm, if not internal-to-hugetlb
function, I see no reason that it should not handle the case of 0.
I haven't studied what hugetlb_dissolve does, or why it can't use the
standard split_folio(), but I'm sure there's a good reason.