support multisymbol and multitimeframe

[drew2323]

Add multisymbol and multitimeframe (multi resolution).

• Allow to resample to lower frequencies than main frequency.
• Allow additional complementary symbols and frequencies.
• For those support
  • required history length
  • update bars and calculate indicators on the fly
  • data source configuration, indicators definitions and conditions building
  • Frontend visualization
• Trademanagement support (only primary symbol tradeable? future enhancements)

Other areas to support:

• runner type (daily/continuous) - (run, display on frontend, visualize metrics etc)
• main session and/or extended hours.
• type of market stocks/crypto/options (tbd one thing is data API, other is trading api)
• definition of multisymbol and multitimeframe, with primary symbol/resolutiionn.
• historical requirements(HR) for each resolution. These are appended as initial values to respective variables during initialization for each resolution (from cache/remote). TBD cover the case of unfinished bars (daily, hours...) - initialize unconfirmed bar with as much available data for realtime updates
• data dispatcher for new_trade or trade_mngmt sections.
• live/paper trading + backtesting

When modeling source data take into consideration adding another economic data as sources.

Example of strategy/sources definition:

• data sources, current add_data

  
  [data source.1]
  id: 1, BAC, CBAR, 5s, required history: 20
  [data.source.2]
  id: 2, BAC, BAR, 15min, req.history: 30
  [data.source.3]
  id: 3, SPY, VBAR, 23000, req.history: 40

[dispatch_triggers] # which resolution triggers the which strategy section new_trade =2 trade_mngmt =1

- indicators and signals, current `stratvars`
```toml
[stratvars.indicators.bac_5s_rsi14]
   source_id = 1
   type = “RSI”
   length = 14
   on_confirmed_only = true
[stratvars.indicators.bac_15min_ma10]
   source_id =2
   type = “MA”
   length = 20
   on_confirmed_only = true
[stratvars.indicators.spy_1h_rsi10]
   source_id = 3
   type = “RSI”
   length = 10
   on_confirmed_only = true

[stratvars.signals.main.conditions]
    #preconditions 

    #SHORT ENTRY
    #signal.go_short_if_equals = -1

    #EXIT PROTECTION
    #slopetick5.dont_exit_long_if_above = 0

    #EXIT
    #divergence_volume.exit_long_if_below = 0.700

    #LONG ENTRY
    bac_5s_rsi14.AND.go_long_if_above = 70

Source identification in Indicator configuration Currently indicator configuration uses source attribute referring to primary resolution and also direct source names (close,RSI,swap,open...) are used within configurable statement. These have to be extended to link to source_id (maybe prefix or other). Support current cbar_indicatotors (tick bases time series).

Examples of current source usage:

    cp.source = 'bars|vwap'  #meaning bars entity and vwap columns, other can be `indicators|rsi14`, used in indicators
    cp.next = ['cbar_indicators|time'] #optional, source posilany explicitne do next ve stejnojmenném parametru - used in classed indicators
    cp.source = "cbar_indicators|tick_price"
    cp.expression = 'close[-1]-(atr10[-1]*2)' #in expression
    cp.source = 'dailyBars|high'

Frontend changes (primary and secondiers chart panes):

• source_ids with same symbol (tradefiltrer and type) can be displayed on same pane with button to switch resolutions.
• source_ids with different symbol are displayed in another synced chart below the primary one
• indicators buttons are linked to each resolution - sourceID (or pane? TBD)
• trades are visible on primary pane

Requirements in progress: https://docs.google.com/document/d/1cHK1Brv92CFUpZF47trB8_IjT0aoQwunB28FJMqINkU/edit?usp=sharing

Current Component diagram

Proposed changes Component diagram

[drew2323]

A new branch feature/multisymbol223 has been created to accommodate all partial changes from local development branches.

[drew2323]

Next steps:

• [x] Data definition and data flow - describe source data entities and their representation(resolutions including tick level, bar types, trade filtering). req doc
• [x] Include data flow and transformation within various processes (ingestion, aggregation, storing and accessing in backend, caching(including file names generation, updates etc ), transformation and usage on frontend. impacted components
• [ ] review internal source data structure to accommodate #230 also review add_data section to cover the same. To avoid changing the structure in the future.
• [ ] Start detail design according to data above. Start with code line by line and add changed sections to dd document.
• [ ] design Initial load of source data based on historical requirements (HR)

[drew2323]

• zvážit ukládání realtime dat a vytváření indikátorů již v agregátoru a použití queue "pouze" pro dispatch strategie
• v backtestu vynutit přesné pořadí jako v LIVE (sloučit trady všech symbolů a sort dle času) - domyslet následný caching z agregatorů(např. společná cache skrz všechny symboly a a gregátory použité a nebo v cache uvádět čas v nanosekundách a umožnit slučování cache více symbolů a následný sorting hodnot pro zajištění časové souslednosti.
• vzhledem ke komplexnosti rozfázovat vývoj - v úvodní fázi nasadit multiresolution na single symbolu. Tzn. pouze předsadit po queue komponentu na downsampling.