delivery: message_dequeue_load_from_mess has broken filename handling

[liske]

We observed that requeuing mails using the suggested unit from the docs does never work.

While tracing continuous coredumps in the most recent gromox 2.43 we found out that it will never work by design. We observed a continuous trashing of readdir on /var/lib/gromox/queue/mess/ with failed openat of gromox-delivery. After some gdb based analysis we found what the process does and the origin of the issue:

1. the mess directory is scanned in mdq_thrwork and for each file which should be processed message_dequeue_load_from_mess is called in L432
2. the filename is not passed as a parameter - instead the string is converted to a long integer using strtol
3. the base parameter is set to 0 - so that the numeric base is derived from the string (so it is interpreted as octal notation, but it is already bricked because of the leading zero)
4. inside of the message_dequeue_load_from_mess function the integer value is converted back (!) to a string using std::to_string => decimal representation

This loops over again and again - what a MESS!

Please consider not to convert filename strings to integer just to convert them back to strings some CPU clocks later (mind the 🌳). IMHO a good approach would be to pass always a filename (string) on message_dequeue_load_from_mess and move the to_string to the msgrcv handling, only.