feat(http): make endpoint report the upstream status code

[btasker]

endpoint() populates the column _sent based on whether upstream returned a 200, however it doesn't report the status code to the caller.

endpoint is used (amongst other things) in 2.x's Notification Rules - not having the status code available can make it quite difficult to troubleshoot why a notification wasn't sent.

With this change, endpoint will include an additional column: status_code

In the context of a notification rule, this will result in entries in _monitoring/notifications carrying the tag status_code, making it possible to graph out notifications by the upstream status code:

from(bucket: "_monitoring")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "notifications")
  |> filter(fn: (r) => exists r["status_code"])
  |> group(columns: ["check_id", "status_code"])
  |> aggregateWindow(every: v.windowPeriod, fn: count)

Note: the addition of this column could cause issues where the result is written into a bucket with an explicit schema.

However, explicit schemas are only available on Cloud 2 - the query log has been checked for any queries which could result in issues, with none identified.

Checklist

Dear Author 👋, the following checks should be completed (or explicitly dismissed) before merging.

• ✏️ Write a PR description, regardless of triviality, to include the value of this PR
• 🔗 Reference related issues
• 🏃 Test cases are included to exercise the new code
• 🧪 If new packages are being introduced to stdlib, link to Working Group discussion notes and ensure it lands under experimental/
• 📖 If language features are changing, ensure docs/Spec.md has been updated

Dear Reviewer(s) 👋, you are responsible (among others) for ensuring the completeness and quality of the above before approval.

[mhilton]

This looks fine to me, but can we just change the standard lib like this?

[sanderson]

To @mhilton's point, we might want to add this to all of the *.endpoint() functions in the stdlib so that they're consistent.

[btasker]

Yeah that's a fair point - I did think it'd be worth adding to at least the Slack and PD ones, but hadn't done the same legwork on looking to see whether there are any unusual uses of them.

I don't love changing the return of something quite so core, but this is causing some pain.

The alternatives seem to be

• Change the notification rule task generator to override endpoint in the tasks it generates - as well as making them all slightly less efficient it'd also be a bit of a pain to do
• Add a new endpointWithStatus function which duplicates endpoint but includes status (and then update the notification rule generator etc etc).

The latter's doable, but feels a little OTT. On the other hand, it would also be safer.

I'll try have a play around tomorrow