improve: Make SlackTransport most robust to HTTP 400

[pxrl]

The SlackTransport class currently throws hard on any exception. This includes an HTTP 400 response from Slack, which is actually indicative of a badly formatted message (or alternatively "bad user"). On the Across side we've seen this throw when logging the "bad" response to an RPC quorum disagreement. Typically this kills the Slack transport entirely because the exception ripples upwards and is never recovered.

This change catches the Axios error (usually an HTTP 400 response) and attempts to re-submit with the truncated JSON as raw text. This is fairly ugly, but has the following benefits:

• It's recorded that a log message was dropped.
• The transport does not halt and can continue to be used.

nb. The underlying reason for this issue that we're truncating and splicing text into long JSON bodies; there's a low probability that this will produce valid JSON again on the other side. Some improvements to that will be submitted separately.

[pxrl]

Note: I pulled this back to draft, since it turns out the version of the SlackTransport we use in Across is old. Newer versions include some fixes that would already give us a big benefit, and might change the approach we take to ensuring that malformed log messages are not discarded. I've got a PR open to bump to the latest version: https://github.com/across-protocol/relayer-v2/pull/992

[pxrl]

Closing in favour of Reinis' PR.