Address Missing StableCoin Pairs in Crypto Exchanges

[C-SELLERS]

Description

Address issues surrounding adding stable coins to algorithms without direct trading pairs for conversion.

Even though an exchange may not offer a direct conversion from a given account currency and stablecoin (ex. GDAX USD -> USDC) we still want to be able to override some handling of these cases. In this specific example we know at GDAX USD -> USDC is a consistent 1-1 conversion. But at another exchange such as Bitfinex there is a tradable security that reflects small variances in USDC price.

To let these both exist and not have the GDAX case throw we add a condition that if there is no currency conversion security found, we first check a new static variable *StableCoinsWithoutPairs in the Currency class that will tell us if a given market should allow the Cash (USDC or other stablecoin) to be added with a 1-1 conversion without tracking a security.

*Maybe needs a better name, something more clear? Possibly relating to the fact they are all 1-1 conversion pairs without securities, or maybe a way to add this to SPD?

I also added two missing pairs to the GDAX SPDB for

• USDC/EUR
• USDC/GBP

Source: https://pro.coinbase.com/markets

Related Issue

Closes #5478

Motivation and Context

Reference issue above

The problem is caused by underlying brokerages not having a direct pair for stablecoins from account currency. If they did Lean would generate a subscription to these assets and update its conversion rate as data for that pair flows through the engine.

This solution seeks to bypass the issue for stablecoins that we know hold a direct 1-1 conversion rate with the account currency.

Following this solution we will likely need to consider multi-leg conversions since there isn't a direct path on some of these exchanges.

Requires Documentation Change

N/A

How Has This Been Tested?

Added a unit test that asserts behavior of this issue with a range of cases for each crypto exchange, account currency, and possible stablecoins.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• 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:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>

[Martin-Molinero]

Please add some unit & regression test around the issue so we can assert the fix 👍

[Martin-Molinero]

Looks good, minor comments only 👍