Adds logic to perpetually keep a send list up to date

[pushchris]

Currently after you create a campaign it does not update the user the list will be going to even if you schedule the campaign for way in the future. The initial rationale behind this is that generating a send is expensive and it's hard to know when to cutoff a list since you could be sending to a disparate group of timezones.

This logic piggybacks off of the performance improvements introduced by rule caching to check for list additions and removals to know if we should re-check a users enrollment in a campaign. If the campaign has not yet started running and a users enrollment changes, we want to reflect that in the campaign by either adding or removing the user from the send. This should at best get you granularity up until the minute before a send and at worst up to 24hrs off depending on the timezone of the user and the other users you are sending to.

[leobarcellos]

@pushchris If I understood it correctly, everytime a list is updated, it will trigger the updateCampaignSendEnrollment function, question is: how often lists are updated? Does it happen like from time to time on the worker instance or does it need a user to actually view the list on the interface?

[pushchris]

Dynamic lists are updated in real time whenever either an identify or event is triggered for a given user