libs: vendor libmpack and libmpack-lua

[bfredl]

• we want to use libmpack to implement msgpack decoding with much less memory overhead (decode directly to API or internal types, not to msgpack-c allocated tree of heap objects)
• expose vim.mpack for plugins Lua: expose mpack #15452

Alternative: bundle these as separate cmake dependencies. This could be done but then someone must write the necessary cmake logic, and my suspicion is that these libs aren't used much outside neovim anyway (msgpack-c is the "official" c bindings).

[bfredl]

This should be pretty much done as a MVP (except an OS X build failure I'm currently investigating fixed). For now only one-shot pack/unpack methods are documented and tested, but support of Sessions will be a natural followup when implementing RPC for lua worker threads and/or remote processes (which are gonna want a wrapper around mpack.Session + vim.loop) .

[justinmk]

is the "pack"/"unpack" a distinct concept from "encode"/"decode"? We have already msgpackparse/msgpackdump (Python convention) and json_ecode/json_decode.

If the distinction is not important it might make sense to call this vim.mpack.encode/decode. Or perhaps from_lua/to_lua ?

[bfredl]

No it's not, I suspect msgpack libs always use "pack" and "unpack" as it rhymes with "msgpack". I don't think from_lua and to_lua makes sense as (1) lua is implied by the context of lua code (2) later we need the nouns such as the Packer and the Unpacker, where the Encoder/Decoder works if there's a strong preference to change it to that, though my honest opinion would be to err at the side of lazyness and keep the msgpack conventions.

[justinmk]

where the Encoder/Decoder works if there's a strong preference to change it to that, though my honest opinion would be to err at the side of lazyness and keep the msgpack conventions.

if you just want to avoid the chore, I am willing to do it :) Consistency (in the scope of our system) helps users a lot.

[bfredl]

is it needed to do this now? marcos.h seems to encode nvim-specific desicions what c compilers we support, and it would make more sense to figure this out when extracting/upstreaming code later (if ever).