ANDROID: mm: Allow non-movable allocations to use virtual zones

In some cases, our demand for mTHP is not as urgent, while the demand
for other resources, such as dma-buf, becomes more pressing. However,
the reserved virtual zones may not be efficiently utilized by dma-buf
and similar use cases. Therefore, if we are absolutely certain that
the product will not require movable zones, we can allow virtual zones
to be allocated for requests with unmovable flags.

After supporting the use of virtual zones for non-movable allocations,
we need to address the large page migration issue triggered by the
pin_user_pages function：
During large folio performance profiling, we found unnecessary performance
loss due to a large number of migrations caused by the pin_user_pages
 function during boot-up and continuous application startup testing.
Call trace:
	dump_stack+0x18/0x24
	folio_add_anon_rmap_ptes+0x294/0x338
	remove_migration_pte+0x268/0x514
	rmap_walk_anon+0x1c8/0x278
	rmap_walk+0x28/0x38
	migrate_pages_batch+0xbc8/0x126c
	migrate_pages+0x16c/0x7a4
	__gup_longterm_locked+0x4a4/0x85c
	pin_user_pages+0x68/0xc4
	gup_local_repeat+0x38/0x1cc [mcDrvModule_ffa]
	tee_mmu_create+0x368/0x804 [mcDrvModule_ffa]
	client_mmu_create+0x58/0xd4 [mcDrvModule_ffa]
	wsm_create+0x44/0x11c [mcDrvModule_ffa]
	session_mc_map+0x174/0x244 [mcDrvModule_ffa]
	client_mc_map+0x34/0x64 [mcDrvModule_ffa]
	user_ioctl+0x704/0x830 [mcDrvModule_ffa]
	__arm64_sys_ioctl+0xa8/0xe4

With TAO enabled, large folio come from either ZONE_NOSPLIT or ZONE_NOMERGE policy zones.
Both of the policy zones are movable zones(Refer to folio_is_zone_movable).
Therefore folio_is_longterm_pinnable will return false and large folio will be added to the
movable_page_list and migrated in the migrate_longterm_unpinnable_pages function.
On the other hand, migrating large folio is costly and involves frequent calls to the deferred_split_folio function.
What's worse is that dst folio will still alloc from two policy zones, the gfp flag will be set to GFP_TRANSHUGE
in the alloc_migration_target function. So the whole migration behaviour seems to become meaningless!

Bug: 313807618
Change-Id: I2fdfc4df8b03daa96fd6c2c8c6630d26a8509ad0
Signed-off-by: Barry Song <v-songbaohua@oppo.com>
Signed-off-by: Shuai Yuanyuan <yuanshuai@oppo.com>
Signed-off-by: Tangquan Zheng <zhengtangquan@oppo.com>