Extend HTTPRequest to support path overrides

[ecooper]

This PR extends the existing HTTPRequest to take an optional path to support POST requests to endpoints other than /query/1.

Description

We'll need to support requests to Fauna APIs beyond /query/1. Today, this API path is hardcoded in both the fetch and http2 client wrappers. This PR does the following:

• Extends HTTPRequest to accept an optional path
• Updates FetchClient to use default API paths, but override per request when one is provided on HTTPRequest
• Updates NodeHTTP2Client to use default API paths, but override per request when one is provided on HTTPRequest
• Adds a readonly FaunaAPI to represent the supported API paths in the driver
• Restricts HTTPRequest["path"] to the union of supported endpoints via FaunaAPI

Motivation and context

We need to support more endpoints in this driver. The current http clients really only have a fixed concept of requesting queries or streaming. This change allows for a backwards compatible way to introduce providing a path without breaking existing code or interfaces.

Alternatives considered:

• Making HTTPClient.request be (path: SupportedFaunaAPIs, req: HTTPRequest): backwards incompat
• Supporting both the signature above and the current one: Seems overly complex
• Adding path to a second optional argument of a new HTTPRequestOptions interface to request: Best alternative, but also lacking much more substance--especially since HTTPRequest already supports additional meta options, like timeout.

In the future, we may want to reconsider redesigning these interfaces in a major version bump, but that is out of scope for this PR.

Definitely open the other implementation approaches!

How was the change tested?

These changes have dedicated unit tests. The unit tests validate the override logic as well as type enforcement.

Because these changes are backwards compatible, all existing code and tests should work as expected.

Screenshots (if appropriate):

N/A

Change types

• • [ ] Bug fix (non-breaking change that fixes an issue)
• • [x] New feature (non-breaking change that adds functionality)
• • [ ] Breaking change (backwards-incompatible fix or feature)

Checklist:

• • [x] My code follows the code style of this project.
• • [ ] My change requires a change to Fauna documentation.
• • [ ] My change requires a change to the README, and I have updated it accordingly.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[ecooper]

i'm ok with this path forward (and with a major version bump that moves these to obj args as well).

how much blast radius is there in the docs site if we make a breaking change in these?

Because these are largely internals they are really only covered by the docs that are auto-published here: https://fauna.github.io/fauna-js/2.2.0/