This enumerator was breaking the enumerator contract and returning
true when the underlying enumerator had finished. Some enumerators
in the live stack must always return true because they're never
really finished but the fast forward is a wrapper around another
enumerator and should respect when the underlying has completed
This commit addresses two existing issues:
1. The datasource is refreshed half as often as it should
2. Data points are emitted on every data source refresh
When running a remote file in live mode with a high resolution (~second), it is possible
for us to download the file, fast forward to the end, and then emit duplicate data.
This change adds an extra filter in the FastForwardEnumerator to prevent it from emitting
data in the past, that is, data the is earlier than the previous piece of data emitted
-- forward only behavior --
This refactor was an effort to bring into line the various concepts between the
FileSystemDataFeed and the LiveTradingDataFeed. The former works using enumerators
and a time sync loop that uses the concept of a frontier to decide when to 'pull-off'
data that's at or before the frontier. This makes the feed uninterested in how the
data (via enumerators) is provided, and only concerns itself with things at the
subscription level, that is, time syncing and universe selection invocation.
These concepts were brought over to the LiveTradingDataFeed with some modification.
This change heavily uses object composition of enumerators to handle the various
concerns that were previously within the enumerator loops in the LiveTradingDataFeed.
Some enumerator types that help accomplish these concerns:
FastForwardEnumerator - fast forwards an enumerator that contains old data
RateLimitEnumerator - prevents an enumerator from being invoked too frequently
TradeBarBuilderEnumerator - Builds trade bars from tick data
FrontierAwareEnumerator - Emits the underlying when the frontier is on or after Current
EnqueableEnumerator - Acts as a liason between a push/pull system using a queue