Improve `PythonIndicator.IsReady` implementation
Description
Since the property BaseIndicator.IsReady does not define a setter, when a custom indicator (which inherited from PythonIndicator) was updated manually, the property IsReady never became true as it was handled internally by PythonIndicator class. This bug was noticeable when using the method IndicatorExtensions.Of with a second indicator because it required the first indicator to be ready in order to update the second one. To fix this bug, I improved the get implementation of the PythonIndicator.IsReady property so that it used the overridden python version of IsReady whenever it was defined. Thus, now if the user is updating manually a custom indicator, it can (and should) override the is_ready method to define when the indicator is ready.
Related Issue
Closes #6615
Motivation and Context
With this change, users will be able to define when an indicator is ready
Requires Documentation Change
These changes might require to brief the community on how the is_ready method must be implemented in order to use that property
How Has This Been Tested?
I created a regression test that creates a custom indicator that updates a second one on its time whenever it's updated (using IndicatorExtensions.SMA). The algorithm updates the custom indicator manually and asserts the indicator is ready at the end.
Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] Refactor (non-breaking change which improves implementation)
- [ ] Performance (non-breaking change which improves performance. Please add associated performance test and results)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Non-functional change (xml comments/documentation/etc)
Checklist:
- [x] My code follows the code style of this project.
- [x] I have read the CONTRIBUTING document.
- [x] I have added tests to cover my changes.
- [x] All new and existing tests passed.
- [x] My branch follows the naming convention
bug-<issue#>-<description>orfeature-<issue#>-<description>