[port] use ragel-bitmap for less memory

[eval]

port of #1623

[eval]

/cc @ahorek

[eval]

@ahorek it seems received_parser.rb was unchanged in the ragel-bitmap PR. This makes sense as the timestamps of the rl-files hadn't changed.
Manually deleting lib/mail/parsers/*.rb and re-running rake ragel:generate revealed it.

Could you approve this PR so it can be merged? I'll add the extra commit to 2-8-stable.
To clean up these files I created #1626 - review welcome as well 🙏🏻

[ahorek]

Nicely spotted! Thanks for catching that.

[ahorek]

👍

[eval]

The approval needs to be from someone with commit rights, it seems... mind to help out with this ported PR @sebbASF ?

[sebbASF]

Sorry, but I'm not convinced that this is a worthwhile change.
Whilst the code may be a bit smaller, it complicates the build process, and may result in stale source.

[eval]

@sebbASF how would you suggest to move fw?

[sebbASF]

Is there really a need to change?

[ahorek]

Compared to other dependencies, this gem has a disproportionately large memory footprint for a simple email parser. This is primarily because Ragel doesn’t generate efficient code for Ruby, and Ruby doesn’t handle large numeric arrays optimally.

#1342 cc @schneems @kddnewton

I don’t believe this complicates the build process. Modifying the Ragel sources requires recompilation regardless, and there’s already a rufo formatter in place. Additionally, the parsers were last updated in 2017, so this change shouldn’t increase maintenance costs.

[kddnewton]

I think this would be a worthwhile change, but ultimately I wouldn't be the one maintaining it so I don't think I can weigh in very heavily. I believe the memory savings are good, but if it's too complicated to understand maybe it's not worth it.

[radar]

I think the addition of benchmarks in this PR would be a worthwhile addition, either in the original PR description or as a comment here. Show us your data :)

[radar]

This may have already been merged in #1623.

[ahorek]

It was only merged into the 2.8 branch except for #1630
If you intend to merge 2.8 into master manually, this PR may not be needed.