Consider extra empty space in BODYSTRUCTURE

[gaynetdinov]

Hi! I'm working on (very old) project that's excessively using net-imap to access remote IMAP servers. Since ages we have some 'imap hacks' implemented on top of net-imap. These hacks were introduced to cope with some unusual responses from IMAP servers of our customers. I thought that I'd try to 'backport' some of them if you'd consider them viable/useful.

In this my first PR I'm 'backporting' one fix we had since 2016. Responses from some IMAP servers contained extra space like so ((\"text\" \"plain\" (\"charset\" \"UTF-8\"). The fix seems to be easy and should not do harm I guess. I'm not sure if the fix is idiomatic according to the recent changes in net-imap (we're bumping net-imap frim 0.3.7 to 0.4.10 right now, so how we implemented the fix long time ago might not be pretty in 0.4.10).

Thank you for your time!

[nevans]

Since ages we have some 'imap hacks' implemented on top of net-imap. These hacks were introduced to cope with some unusual responses from IMAP servers of our customers. I thought that I'd try to 'backport' some of them if you'd consider them viable/useful.

That's great! My experience is very similar. :) And, I hope the jump from 0.3.7 to 0.4.10 isn't too difficult. As you've probably seen, some of the biggest parser changes were in the BODYSTRUCTURE code. And I have even more patches that I still haven't integrated into net-imap, yet!

I'm not sure if the fix is idiomatic according to the recent changes in net-imap

That's no problem. The updates are quite simple. I added a couple of suggestions. Thanks!

[nevans]

I'll add that I do have some concerns about simply skipping over extra spaces in general, because I have seen (or maybe I only misremembered seeing?) servers mistakenly send nothing rather than NIL, which converts " NIL " into " ". But since you've run this since 2016 with no noticeable issues (and it passes all other tests), I think it should be safe.