[snowflake][ccm] Add query tag documentation

[BoyangHuang]

What does this PR do? What is the motivation?

Merge instructions

Merge readiness:

• Ready for merge

Merge queue is enabled in this repo. To have it automatically merged after it receives the required reviews, create the PR (from a branch that follows the <yourname>/description naming convention) and then add the following PR comment:

/merge

Additional notes

[github-actions]

Preview links (active after the build_preview check completes)

Modified Files

• https://docs-staging.datadoghq.com/bo_huang/snowflake-query-tags/cloud_cost_management/saas_costs

[cswatt]

Just a few styleguide edits and suggestions for clarity.

[cswatt]

Suggested change

	[Snowflake's query tags][106] are powerful metadata strings that can be associated with queries. The Snowflake Cost Management integration will ingest [JSON parsable][107] query tags present in a comma-separated allowlist found in the Snowflake integration tile.
	[Snowflake's query tags][106] are powerful metadata strings that can be associated with queries. The [Snowflake Cost Management integration][101] ingests [JSON parsable][107] query tags present in a comma-separated allowlist found in the Snowflake integration tile.

Adding a link to tile to the phrase "Snowflake Cost Management integration", as I don't believe we've used this name before on this page, and it's not immediately clear that this is the topic we're already talking about, as opposed to a new additional integration that the user has to also set up

[cswatt]

Suggested change

	As a result, the costs of all queries executed with the `team` and `application` query tags will be attributable to those concepts.
	As a result, the costs of all queries executed with the `team` and `application` query tags are attributable to those concepts.

[cswatt]

Suggested change

	In order to leverage query tags within cost management, you must ensure that the following rules are adhered to.
	To use query tags within cost management, ensure the following:

[cswatt]

You used the words "first" and "secondly" here, but it seems to me that there isn't any ordering (for example, first condition must be fulfilled before you can fulfill the second condition) to these two conditions. For that reason, I would recommend using an unordered list instead:

Suggested change

	First, the query_tag string must be JSON parsable. Specifically, this means that the string is processable by the native PARSE_JSON function.
	Secondly, an allowlist of keys must be provided in the Snowflake integration tile. These keys map to the first layer of the JSON formatted query_tag field. This allowlist will appear in the form of a comma-separated list of strings, e.g. tag_1,tag_2,tag_3. Please ensure that strings are only alphanumeric characters, or underscores, hyphens, and periods. This information can be entered into the Snowflake tile, under “Resources Collected -> Cloud Cost Management -> Collected Query Tags”
	- The `query_tag` string must be JSON parsable. Specifically, this means that the string is processable by the native `PARSE_JSON` function.
	- An allowlist of keys must be provided in the Snowflake integration tile. These keys map to the first layer of the JSON-formatted `query_tag` field. This allowlist appears in the form of a comma-separated list of strings for example: `tag_1,tag_2,tag_3`. Ensure that strings contain only alphanumeric characters, underscores, hyphens, and periods. You can enter this information into the Snowflake tile, under **Resources Collected -> Cloud Cost Management -> Collected Query Tags**.

I changed "Please ensure that strings are only alphanumeric characters, or underscores, hyphens, and periods." to "Ensure that strings contain only alphanumeric characters, underscores, hyphens, and periods." Is this the meaning you intended?

[cswatt]

Suggested change

	**Snowflake Query Tags**
	**Snowflake query tags**

[cswatt]

Suggested change

	Notes:
	- **Optimizing tags**: Although a powerful concept, query tags should be selected with data magnitude in mind. Appropriate query tags are ones that have low to medium group cardinality (e.g. team, user, service). As the number of unique values increases, bottlenecking issues for both data ingestion and frontend rendering can manifest. An example of a suboptimal query tag is the unique UUID associated with job executions.
	**Note**: Select your query tags with data magnitude in mind. Appropriate query tags are ones that have low to medium group cardinality (for example: team, user, service). Selecting a query tag with high group cardinality (such as unique UUID associated with job executions) can result in bottlenecking issues for both data ingestion and frontend rendering.