Provide a way of limiting the mail storage size

[kjagiello]

MailDev may sometimes be used as a part of a development/staging environment where the process may be running for a very long time without interruption. In those cases, it is undesirable to let that
process grow freely. This limit makes sure that the memory usage is bounded.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@0ff1f28). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master     #237   +/-   ##
=========================================
  Coverage          ?   65.37%           
=========================================
  Files             ?        9           
  Lines             ?      517           
  Branches          ?      109           
=========================================
  Hits              ?      338           
  Misses            ?      179           
  Partials          ?        0

Impacted Files	Coverage Δ
lib/mailserver.js	66.98% <100%> (ø)
index.js	72.5% <100%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0ff1f28...a7b1ce6. Read the comment docs.

[kgeis]

This is a great feature, and I am looking forward to using it.

Thank you for including a test. Here's what I'd like to see before pulling:

• Update the Usage section of README.md to document the new option.
• Apply the setting with a setter like how autoRelay is done. I see this as a less-used property of mailServer, and I don't want an explosion of parameters on the create(..) method.
• Remove repetition of email count in the test (one instance of 2, two instances of 3, and transporter.sendMail() being called three times).

[kjagiello]

@kgeis

• Update the Usage section of README.md to document the new option.
• Apply the setting with a setter like how autoRelay is done. I see this as a less-used property of mailServer, and I don't want an explosion of parameters on the create(..) method.

Good points! Fixed!

• Remove repetition of email count in the test (one instance of 2, two instances of 3, and transporter.sendMail() being called three times).

I did find some flaws in the test, so I have redone it now. Take a look at it and let me know you see any more issues there.

[kjagiello]

Also, as you can see in the test, I had to clear the store, because it contained leftovers from the previous test cases. We should probably empty the store every time a new EmailServer is created (under the assumption that there should be max one running instance of it)?

[kjagiello]

@kgeis Do you think we could this merged in sometime soon?