Fix flush interval

[Darthmineboy]

Fixes auto commit at flush interval not being triggered due to constant stream of messages which resets the flush interval.

I was having a bit of an issue with CI that it says There were failures detected in the following suites: stream ./pkg/stream but I was unable to see the failing test. I upgraded ginkgo because I thought it may be related to onsi/ginkgo#973 where test summary is not shown when just 1 test fails.

Turns out that this failure was caused by a data race that was logged as warning but it doesn't mark a specific test as failed. The data race is now fixed. If you want I can revert the ginkgo upgrade.

fixes #337

[Gsantomaggio]

Thank you. I put @hiimjako in the cc to check the PR.

[hiimjako]

Looks great to me!

I was also thinking:

1. If the lock in cacheStoreOffset is needed, because it doesn't look like there are concurrent calls to the function.
2. If it makes sense to move the reset of messageCountBeforeStorage into cacheStoreOffset, along with lastAutoCommitStored, so that every time you store the offset, both values are reset. Because right now is not when is triggered in the case <-time.After(consumer.options.autoCommitStrategy.flushInterval).

[Gsantomaggio]

Thanks both.
@hiimjako feel free to merge when it is ok with you

[Darthmineboy]

I'll make some improvements after work

[Darthmineboy]

Looks great to me!

I was also thinking:

1. If the lock in cacheStoreOffset is needed, because it doesn't look like there are concurrent calls to the function.
2. If it makes sense to move the reset of messageCountBeforeStorage into cacheStoreOffset, along with lastAutoCommitStored, so that every time you store the offset, both values are reset. Because right now is not when is triggered in the case <-time.After(consumer.options.autoCommitStrategy.flushInterval).

1. I thought so as well, but the tests were failing due to a data race. What happens concurrently though is closing the consumer, which would cause the data race. I've made an additional change to resolve another data race issue.
2. I've moved resetting messageCountBeforeStorage so that it applies to both cases.

[hiimjako]

What happens concurrently though is closing the consumer, which would cause the data race.

Yeah, right, it also makes sense having both values in a lock.
To avoid it, maybe we could make a channel to stop the consumer routine and fill it at the beginning of the close function, so you don't have concurrent calls, but I would say leave it for future PR.

That's fine for me, thanks for the contribution 😄

[Gsantomaggio]

Thanks @Darthmineboy @hiimjako