feat: add fee detector

[marktoda]

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

• What is the current behavior? (You can also link to an open issue here)

• What is the new behavior (if this is a feature change)?

• Other information:

[marktoda]

> validation.getFeesByToken(new Token(1, '0xaBeC00542D141BDdF58649bfe860C6449807237c', 18))
{
  buyFeeBps: BigNumber { _hex: '0x64', _isBigNumber: true },
  sellFeeBps: BigNumber { _hex: '0x64', _isBigNumber: true }
}
>

[zhongeric]

Lgtm, are we planning on deprecating the old token-validator-provider? Also, are we planning on adding this to AlphaRouter or just have it exported for use in i.e. frontend?

[jsy1218]

Lgtm, are we planning on deprecating the old token-validator-provider? Also, are we planning on adding this to AlphaRouter or just have it exported for use in i.e. frontend?

From the slack thread, it sounds like interface will use it as FOT workaround to begin with. routing team still evaluating whether we need to take on quoting FOT after we mitigate the quote latencies.

[marktoda]

Lgtm, are we planning on deprecating the old token-validator-provider

The old one still serves a different purpose! it categorizes based on whether the token has a fee at all, or fails on transfer. It also allows checking against multiple bases, which doesn't make as much sense here because which fee would we show if it was different depending on the base

[andysmith415]

Appreciate you jumping on this @marktoda! Handful of comments, feel free to ping me for any questions; happy to elaborate.

[mikeki]

I'm also not a fan of returning anonymous functions as part of the response rather than objects of a specific class.

Could we instead do:

export class TokenFeeResults {
  constructor(private readonly tokenToResult: { [tokenAddress: string]: TokenFeeResult }) {}
  
  getFeesByToken(token: Token): TokenFeeResult | undefined {
    return this.tokenToResult[token.address.toLowerCase()];
  }
}

and here return:

  return new TokenFeeResults(tokenToResult);

[jsy1218]

As I'm working on the router backend support for FOT, I realized that this TokenFeeProvider is tightly coupled with the in-memory ICache. We will need both in-memory memory (for client-side fallback), as well as dynamo caching (for routing-api distributed caches).

I think I will create another PR, meanwhile leveraging the insights and feedbacks from this PR.