Add page for HTTP Query API for Core and Enterprise

[pauldix]

To be merged after #5791

[jstirnaman]

Fixes and suggestions.

[jstirnaman]

Suggested change

	This guide shows some of the capabilities of the HTTP API API for querying and accessing useful information from system tables.
	Learn how to use the HTTP API to query and access information about the database server and table schemas.

[jstirnaman]

Suggested change

	> [!Note]
	> #### system_ sample data
	>
	> In this guide, tables with `"table_name":"system_` represent CPU, memory, disk, network, and other resource usage statistics written by the user to the database for storage and querying.
	> For example, you can use [Telegraf](https://docs.influxdata.com/telegraf/v1/get-started/) to collect and write metrics from your system to an InfluxDB 3 database.

[jstirnaman]

Suggested change

	For example, running the `show tables` query, which will show all user created tables (listed as `table_schema` of `iox`), system tables, and information schema tables. Here's the command:
	For example, run the `show tables` query to view all user-created tables (`"table_schema":"iox"`), system tables, and information schema tables:

[jstirnaman]

Suggested change

	Returns the following JSONL output
	The response body contains the following JSONL:

[jstirnaman]

Suggested change

	SELECT * FROM information_schema.columns where table_schema = 'iox' AND table_name = 'system_cpu'
	SELECT * FROM information_schema.columns where table_schema = 'iox' AND table_name = 'system_swap'

[jstirnaman]

Suggested change

	Schedule plugins are set with a `trigger-spec` of `schedule:<cron_expression>`. The `args` parameter can be used to pass configuration to the plugin. For example, if we wanted the above plugin to run the check every minute, we would use `schedule:*/5 * * * *` as the `trigger-spec`.
	Schedule plugins are set with a `trigger-spec` of `schedule:<cron_expression>`. The `args` parameter can be used to pass configuration to the plugin.
	For example, to run the plugin in the preceding example every minute, use `schedule:*/5 * * * *` as the `trigger-spec`.

[jstirnaman]

Suggested change

	Schedule plugins run on a schedule specified in cron syntax. The plugin will receive the local API, the time of the trigger, and any arguments passed in the trigger definition. Here's an example of a simple schedule plugin:
	Schedule plugins run on a schedule specified in cron syntax. The plugin receives the local API, the time of the trigger, and any arguments passed in the trigger definition.
	The following example shows a simple schedule plugin:

[jstirnaman]

Suggested change

	On Request plugins are triggered by a request to a specific endpoint under `/api/v3/engine`. The plugin will receive the local API, query parameters `Dict[str, str]`, request headers `Dict[str, str]`, request body (as bytes), and any arguments passed in the trigger definition. Here's an example of a simple On Request plugin:
	On Request plugins are triggered by a request to a specific endpoint under `/api/v3/engine`.
	The plugin receives the local API, query parameters `Dict[str, str]`, HTTP request headers `Dict[str, str]`, HTTP request body (as bytes), and any arguments passed in the trigger definition.
	The following example shows a simple On Request plugin:

[jstirnaman]

Suggested change

	On Request plugins are set with a `trigger-spec` of `request:<endpoint>`. The `args` parameter can be used to pass configuration to the plugin. For example, if we wanted the above plugin to run on the endpoint `/api/v3/engine/my_plugin`, we would use `request:my_plugin` as the `trigger-spec`.
	When creating a trigger for an On Request plugin, set the `trigger-spec` to `request:<endpoint>.
	For example, to create an HTTP API `/api/v3/engine/my_plugin` endpoint that runs the plugin in the preceding example, pass `request:my_plugin` as the `trigger-spec`.
	You can use the `args` parameter to pass any additional configuration to the plugin.

[jstirnaman]

Suggested change

	Trigger specs must be unique across all configured plugins, regardless of which database they are tied to, given the path is the same.
	Because all On Request triggers for a server use the same `/api/v3/engine` root path, trigger specs must be unique across all configured plugins, regardless of which database they are associated with.