Added easing event and fixed currentLag

[sashahilton00]

Added an easing event (was running tests and was useful to have), and a new configuration method, consecutiveLags(int), which allows one to configure the number of lag spikes required before the onLag() function is triggered.
Additionally, a change to line #186 was made, as the currentLag was being set to NaN as a result of currentlag being set to a number multiplied by 0 (initial currentLag) in previous iterations. Calculations can now occur properly.

[STRML]

@sashahilton00 Do you recall how currentLag could become NaN in https://github.com/STRML/node-toobusy/pull/22/files#diff-e6e8de65de6907b2e4611b24fc250cb5R186? Multiplying by 0 should result in 0, not NaN.

[sashahilton00]

It's been a while, and I don't remember exactly why it was returning NaN as opposed to 0. I just did a quick search through my drive to find what project was using this, and after looking through, there is a line in there which is toobusy.maxLag(70) with a note about needing to call that in order to avoid the NaN error. I assume I just forked this project at the time, implemented the quick fix || 0 and left it in this commit as it might have been useful for someone else encountering a similar error. That's just my guess though.

[STRML]

Hmm. If highWater were set to 0,

node-toobusy/toobusy.js

Line 39 in 181b58f

var pctToBlock = (currentLag - highWater) / highWater;

would come out to NaN, and all traffic would be blocked ((0.1 < NaN) === false). But I can't see how that would happen.

[sashahilton00]

To be honest, neither am I. I mostly stopped using node a year or so ago, and can't recall the cause of this particular issue. If one were being rigid, I guess you could track down the origin of the NaN through inserting extreme values and testing, but another part of me says that given the or condition, it shouldn't lead to any unexpected behaviour, and should just act as a fallback where the previous statement should be zero anyway if it is being hit.