Bulk APIs on chunk management

[Mili-ssm]

I've searched existing issues and couldn't find a duplicate.

• I confirm this is not a duplicate.

Is your feature request related to a problem? Please describe.

With a bunch of stuff this feature will make the Chunk Linear format (PR #494) "usable".
_{pd: Bulk function/API is that use an slice/Vec as argument instead of an only one element.}

The general point is that:

• Bulk function can reach to better performance improvements or make some abstraction worth.
  _{(nice for more maintainable and flexible code that other wise could be not acceptable)}

• Bulk functions usually get advantage (without special code) of things like cache locality, nice for loops and CPU intensive code.
  _{(making better use of RAM and cache memory bandwidth)}

• Bulk function can make better async/sync code management as getting 1 lock for a entire slice of entitys/ops instead 1 lock for EVERY entity/op.
  _{(ie. 1 file lock to write many chunks instead of a 1 file lock for every chunk you want to write)}

Describe the solution you'd like

I would like to use this issue (or other if you want) as guidelines for how to approach this thing, discuses about it, and follow some issues and PRs working for or depending on this.

Ez Guidelines

• Be careful with Rayon. Is usually better to call the slice version than the one elemnt version with par_iter loop.

• When you make 2 functions (one elment and slice version), the main function is the slice version. _{(even the only one)}

//wrapper for ez of use
fn process_item(item: Item){
    process_items(&[item])
}

//main one
fn process_items(items: &[Item]){
 ...
}

Future Ideas

• Bulk writes/reads api for chunks data from files.
• Bulk writes/read api for entities.

Final

Please share your own ideas and opinions about this and where else it can be helpful.