Introduce bridge-commons

[rzadp]

No description provided.

[akolotov]

Thanks to @patitonar - he has formulated the set of improvements that could increase the part of the code in commons part of the monorepo:

Extract to commons:

• fetchGasPrice methods are similar on Oracle, monitor and UI Common gasprice #179
• getTokenType used on UI, monitor and Oracle (initialChecks.js) Common getTokenType used on UI, monitor and Oracle #165
• getValidatorList, processValidatorsEvents and parseValidatorEvent used on UI and monitor Common Validator utils #181

Fix

• Oracle should use ERC_TYPES from commons Oracle using ERC_TYPES from commons #163
• UI HomeStore should use HomeBridgeV1Abi from commons UI using abis from commons #164

[rzadp]

@akolotov @patitonar
I have a question regarding fetchGasPrice.

Digging into the code and trying to make it common, I noticed some differences:

Fallback

If the call to gas price API fails, then:

• oracle falls back to bridgeContract.methods.gasPrice().call()
  • If it fails, it falls back to x_GAS_PRICE_FALLBACK
• monitor and ui fall back to x_GAS_PRICE_FALLBACK, without calling the contract

Limits

• oracle limits the fetched gas price within GAS_PRICE_BOUNDARIES
• monitor and ui do not

Should we update monitor and ui or should we preserve the differences?

---

Naming

On a side note, the fact that we fetch the gas price from "Gas Price Oracle" is confusing, because we have the Oracle component. Maybe we should rename it?

Maybe like so:

• HOME_GAS_PRICE_ORACLE_URL => HOME_GAS_PRICE_URL
• fetchGasPriceFromOracle => fetchGasPriceFromUrl

[patitonar]

@rzadp Thanks for the analysis, I think we should preserve the differences regarding fallback and limits since it is the correct behavior. Only oracle is required to call bridgeContract.methods.gasPrice().call() as a first fallback value and also to apply the gas price boundaries.

Regarding the naming, I agree that changing the name will help to avoid confusions with the oracle component, so I'm OK with it. Let's wait for @akolotov thoughts on this

[akolotov]

I agree that the current differences regarding fallback and limits are OK:

• getting the fallback price for UI differs from getting the fallback price for the oracle since in the first case the price could be manually adjusted by the end user anyway, in the second way it is better to provide automatic way to get the best price,
• limits are not applicable for UI since user could set up any gas price to manipulate the speed of the transactions
• limits are not applicable for the monitor since it does not send transactions at all

For the naming I suggest to rename the gas price oracle to the gas price supplier.

[rzadp]

Created #180 for renaming.