NotificationRules: provide more explicit information on notification error

Thank you for suggesting an idea to improve InfluxData UI.

- Please ask usage questions on the Influx Community site.
- https://community.influxdata.com/
- Please add a :+1: or comment on a similar existing feature request instead of opening a new one.
- https://github.com/influxdata/ui/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+is%3Aclosed+sort%3Aupdated-desc+label%3A%22kind%2Ffeature+request%22+

**Proposal:**
When viewing a notification rule, where the last run ended in failure, it would be helpful to provide more information from the log to help the user understand, what is at issue.

**Current behavior:**
Currently there is a warning triangle indicating something is wrong. Hovering over the triangle shows a tooltip which always contains the simple message `Last Run Status: Completed(failed)`. This kind of information can already be intuited by the warning icon.


**Desired behavior:**
The tooltip or a popup could contain more information, which can be retrieved from task logs. For eample.
```
from(bucket: "_tasks")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r["_measurement"] == "runs")
|> filter(fn: (r) => r["_field"] == "logs")
|> filter(fn: (r) => r["status"] == "failed")
```
Yields a _value which contains

```
[{"runID":"0831f73d28e82001","time":"2021-09-24T12:55:00.01503072Z","message":"Started task from script: \"import \\\"influxdata/influxdb/monitor\\\"\\nimport \\\"http\\\"\\nimport \\\"json\\\"\\nimport \\\"experimental\\\"\\n\\noption task = {name: \\\"Critical ALL\\\", every: 1m, offset: 0s}\\n\\nheaders = {\\\"Content-Type\\\": \\\"application/json\\\"}\\nendpoint = http[\\\"endpoint\\\"](url: \\\"http://13.57.248.121:3000\\\")\\nnotification = {_notification_rule_id: \\\"0831b7f697f8c000\\\", _notification_rule_name: \\\"Critical ALL\\\", _notification_endpoint_id: \\\"0831b7dbb803e000\\\", _notification_endpoint_name: \\\"AWS micro\\\"}\\nstatuses = monitor[\\\"from\\\"](start: -2m)\\ncrit = statuses |\u003e filter(fn: (r) =\u003e r[\\\"_level\\\"] == \\\"crit\\\")\\nall_statuses = crit |\u003e filter(fn: (r) =\u003e r[\\\"_time\\\"] \u003e= experimental[\\\"subDuration\\\"](from: now(), d: 1m))\\n\\nall_statuses |\u003e monitor[\\\"notify\\\"](data: notification, endpoint: endpoint(mapFn: (r) =\u003e {\\n body = {r with _version: 1}\\n\\n return {headers: headers, data: json[\\\"encode\\\"](v: body)}\\n}))\""},{"runID":"0831f73d28e82001","time":"2021-09-24T12:55:00.491942765Z","message":"trace_id=377fcb7af3b36873 is_sampled=false"},{"runID":"0831f73d28e82001","time":"2021-09-24T12:55:00.49565891Z","message":"Completed(failed)"},{"runID":"0831f73d28e82001","time":"2021-09-24T12:55:00.503034976Z","message":"Error exhausting result iterator; Err: runtime error @15:17-19:4: notify: failed to evaluate map function: Post \"http://13.57.248.121:3000\": dial tcp 13.57.248.121:3000: connect: connection refused: runtime error @15:17-19:4: notify: failed to evaluate map function: Post \"http://13.57.248.121:3000\": dial tcp 13.57.248.121:3000: connect: connection refused"}]
```
The final error message could be parsed from this and made available to the user.

```
"message":"Error exhausting result iterator; Err: runtime error @15:17-19:4: notify: failed to evaluate map function: Post \"http://13.57.248.121:3000\": dial tcp 13.57.248.121:3000: connect: connection refused: runtime error @15:17-19:4: notify: failed to evaluate map function: Post \"http://13.57.248.121:3000\": dial tcp 13.57.248.121:3000: connect: connection refused"}
```

**Alternatives considered:**
The information can be obtained through Explorer query-builder, when one knows or figures out where to look.


**Use case:**
When debugging alerts and notifications, which at first can appear a bit complex, it is helpful for more quickly understanding why notifications are not being delivered. For example the endpoint may be down, or an invalid URL may have been supplied.

N.B. I was disappointed to find I could not use an HTTP listener on my laptop for testing against k8sidpe, because the assigned IPv4 address is from the reserved group 192.168.x.x on the local network and it took a while to discover that such URLs are blacklisted. Of course after a moment of consideration, this makes perfect sense, when a user will most likely be creating notifications in the cloud. However, there are other use cases, for example when a listener goes off line, where such information would be more valuable, especially when made easily available.