Support VmMapping::resize

[LclclcdIsACat]

The current implementation of VmMapping lacks the capability to actively resize; it solely relies on merging adjacent VmMappings when their permissions are identical.

This functionality deficiency becomes prominent in user heap management, wherein the system creates a mapping of size USER_HEAP_SIZE_LIMIT for the user's heap and only adjusts the size of the VMO within the mapping when brk is called.

A more appropriate strategy would be to initially establish a modest-sized mapping for the user heap, specifically USER_HEAP_INIT_SIZE, and directly resize this mapping as needed during 'brk' operations, with USER_HEAP_SIZE_LIMIT serving as the upper boundary. Adopting this approach is mainly due to the usual absence of system-imposed limitations on user heap size. It's impractical to set up an excessively large mapping initially, as it should naturally expand in response to actual demands.

Looking ahead, after the completion of page table and page metadata tasks, we ought to consider removing VMOs from the virtual address management in a manner that maintains system efficacy and stability.

[LclclcdIsACat]

@cchanging I need your input on this issue.

[cchanging]

A more appropriate strategy would be to initially establish a modest-sized mapping for the user heap, specifically USER_HEAP_INIT_SIZE, and directly resize this mapping as needed during 'brk' operations, with USER_HEAP_SIZE_LIMIT serving as the upper boundary

I agree. This is exactly the approach in Linux. resize method is required if we want to remove the usage of Vmo from VmMapping. It is also used for mremap syscall.

The implememtation seems straight-forward but should still caution with it. We can leverage the BTreeMap and LinkedList to fastly find the adjacent VmMappings to guarantee the safety of the resizing instruction. I think we can start working on this task soon.