* `@0x/contracts-erc20-bridge-sampler`: Add TwoHopSampler + refactor
* `@0x/asset-swapper`: Refactor + add two-hop skeleton
* Round out two-hop support in asset-swapper
* Add BalancerSampler, use it for two-hop quotes
* Fix bugs discovered from simbot
* rebases are hard
* Add intermediate token to MultiHop source breakdown
* Fix market buy bugs
* Use hybrid on-chain/off-chain sampling for Balancer
* Another day, another rebase
* Update changelogs
* Address PR feedback, CI fixes
* Address more PR feedback
It was added due to the introduction of the use of the TakerRequest type
from @0x/quote-server, as it's included in that structure. However,
that structure is primarily used within the quote server as the output
of parameter parsing, and that parsing routine transforms the API key
HEADER from the request into the TakerRequest type. In short, the API
key is input as a header, not a parameter.
Addresses review comment
https://github.com/0xProject/0x-monorepo/pull/2582#discussion_r437624647
* Include in RFQ-T info log entry the query parameters that were sent to
the maker.
* Re-organize log entry
* Rename top-level field from rfqtMakerResponse to
rfqtMakerInteraction.
* Create separate `request` and `response` sub-objects.
* Rename field `latency` to `latencyMs`.
* Change QuoteRequestor logger parameters to conform to pino logging
library, duplicating (one of) their LogFunction prototype interfaces for
our purposes here. With this, every log emission now includes BOTH a
human-readable message AND a JSON object. Also, this pattern has been
applied to both the error logger and the info logger.
* Do better handling of Axios errors when logging them. Before we were
(a) logging errors in a separate log entry than the message that
explains it, and (b) dumping the whole error object to the log entry,
which was resulting in an object so massive that pino/Kibana was
splitting it into 3 separate entries. Now, we (a) follow the pattern
described in the previous bullet, which puts the error object and the
human readable message into the same log entry, and (b) we check to see
if an error object is Axios-specific, and if so then we use the
AxiosError.toJSON() method to strip out the irrelevant properties.
* Log a uniform maker response metric, with maker endpoint URL, status
code, and latency, for both successful cases and erroneous ones.
(Before, we were only doing this for successful cases.)