chore: Move technical guides to the guide directory (#3371)

<!-- Feel free to delete comments as you fill this in -->
- Move technical guides to the guide directory.
- Update the links to point to the new location.
- Merge identifiers documents.
- Replace a few links with relative links in the registry. This is done
like links to the identifier guide in the secondary connection resource.
- Update links to `execute` resource.
- Add a note about assigning a resource monitor to account.

CREATING_ISSUES.md

@@ -96,15 +96,15 @@ To see what SQLs are being run you have to set the `TF_LOG=DEBUG` environment va
 To confirm the correctness of the SQLs, refer to the [official Snowflake documentation](https://docs.snowflake.com/).
 
 ### How can I import already existing Snowflake infrastructure into Terraform?
-Please refer to [this document](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/docs/technical-documentation/resource_migration.md#3-two-options-from-here)
-as it describes different approaches of importing the existing Snowflake infrastructure into Terrafrom as configuration.
+Please refer to [this document](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/docs/guides/resource_migration.md#3-two-options-from-here)
+as it describes different approaches of importing the existing Snowflake infrastructure into Terraform as configuration.
 One thing worth noting is that some approaches can be automated by scripts interacting with Snowflake and generating needed configuration blocks,
 which is highly recommended for large-scale migrations.
 
 ### What identifiers are valid inside the provider and how to reference one resource inside the other one?
-Please refer to [this document](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/docs/technical-documentation/identifiers_rework_design_decisions.md)
-- For the recommended identifier format, take a look at the ["Known limitations and identifier recommendations"](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/docs/technical-documentation/identifiers_rework_design_decisions.md#known-limitations-and-identifier-recommendations) section.
-- For a new way of referencing object identifiers in resources, take a look at the ["New computed fully qualified name field in resources" ](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/docs/technical-documentation/identifiers_rework_design_decisions.md#new-computed-fully-qualified-name-field-in-resources) section.
+Please refer to [this document](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/docs/guides/identifiers_rework_design_decisions.md)
+- For the recommended identifier format, take a look at the ["Known limitations and identifier recommendations"](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/docs/guides/identifiers_rework_design_decisions.md#known-limitations-and-identifier-recommendations) section.
+- For a new way of referencing object identifiers in resources, take a look at the ["New computed fully qualified name field in resources" ](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/docs/guides/identifiers_rework_design_decisions.md#new-computed-fully-qualified-name-field-in-resources) section.
 
 ## Commonly known issues
 ### Old Terraform CLI version

ROADMAP.md

@@ -19,7 +19,7 @@ We have released a long-awaited [v1.0.0](https://github.com/Snowflake-Labs/terra
 Since the last update we have focused on:
 
 * [Reducing the feature gap](#reducing-the-feature-gap) (focusing on the Snowflake essential GA resources)
-* Redesigning identifiers (check [\#3045](https://github.com/Snowflake-Labs/terraform-provider-snowflake/discussions/3045) and [identifiers_rework_design_decisions](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/docs/technical-documentation/identifiers_rework_design_decisions.md))
+* Redesigning identifiers (check [\#3045](https://github.com/Snowflake-Labs/terraform-provider-snowflake/discussions/3045) and [identifiers_rework_design_decisions](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/docs/guides/identifiers_rework_design_decisions.md))
 * Reworking the provider's configuration (the doc/discussion will be shared when ready)
 * Researching the object renaming in our provider (the doc will be shared when ready)
 

docs/technical-documentation/grant_ownership_resource_overview.md → docs/guides/grant_ownership_resource_overview.md

@@ -1,4 +1,11 @@
-# Grant ownership summary
+---
+page_title: "Grant Ownership"
+subcategory: ""
+description: |-
+
+---
+
+# Grant ownership
 
 The [grant\_ownership resource](https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest/docs/resources/grant_ownership) was introduced in version 0.88.0.
 Since its release, feedback indicates that it can be challenging to understand and use effectively in certain scenarios.
@@ -15,7 +22,7 @@ where granting ownership is crucial and a role-based approach is not feasible.
 After reviewing these use cases, we decided to offer this resource, but with only essential functionalities to keep it simple while meeting necessary requirements.
 
 Over time, we've found it challenging to use, especially when debugging role-based access errors.
-Because of that, we provided [examples of common use cases and error handling](https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest/docs/guides/grant_ownership_common_use_cases) to help resolve most frustrations that come up when using the grant\_ownership resource.
+Therefore, in the coming week, we will provide examples for common use cases and error handling to help resolve most frustrations that come up when using the grant\_ownership resource.
 
 ## Limitations and workarounds
 

docs/technical-documentation/grants_redesign_design_decisions.md → docs/guides/grants_redesign_design_decisions.md

@@ -1,3 +1,12 @@
+---
+page_title: "Grant Redesign"
+subcategory: ""
+description: |-
+
+---
+
+# Grant redesign
+
 ## Why did we decide to do a grant redesign?
 Multiple factors led us to refactor grant resources, the most notable being:
 - Grant problems were the majority in our GitHub issues page. We wanted to resolve all of them by providing a better solution.
@@ -23,45 +32,45 @@ Here’s a list of resources and data sources we introduced during the grant red
 ## Design decisions
 
 ### Implicit enable_multiple_grants enabled by default
-With the grant resources replacement, we wanted to change some of the default behaviors. 
-One of those defaults would be to make grant resources only care about privileges granted by them, mimicking the old **enable_multiple_grants** field enabled. 
-The motivation behind this was consistency with other resources. Other resources work in a way that they only care about themselves and manage the objects they are configured for. 
-Additionally, having such a destructive default could lead to some unexpected grants being revoked if someone forgets to set the flag. 
+With the grant resources replacement, we wanted to change some of the default behaviors.
+One of those defaults would be to make grant resources only care about privileges granted by them, mimicking the old **enable_multiple_grants** field enabled.
+The motivation behind this was consistency with other resources. Other resources work in a way that they only care about themselves and manage the objects they are configured for.
+Additionally, having such a destructive default could lead to some unexpected grants being revoked if someone forgets to set the flag.
 Right now, there’s no alternative to the behavior **enable_multiple_grants** set to false, but we’re considering a flag for that case ([see future topics section](#future-topics)).
 
 ### Workaround for on_all and all_privileges (the always_apply parameter)
 As with the **on_future** field, granting **all_privileges** or granting **on_all** also raised a few questions about tracking granted objects.
-Mostly, it boiled down to running the GRANT statement whenever something changes in the Snowflake infrastructure in the case of **on_all** or whenever a privilege was added to/removed from Snowflake in the case of **all_privileges**. 
+Mostly, it boiled down to running the GRANT statement whenever something changes in the Snowflake infrastructure in the case of **on_all** or whenever a privilege was added to/removed from Snowflake in the case of **all_privileges**.
 We still have to discuss how and if we would like to have internal tracking of the objects affected by those commands.
 
-For now, we decided to add the **always_apply** parameter that always produces a Terraform plan which re-grants specified privileges per terraform apply command execution. 
-It’s worth noting that the workaround doesn’t meet with the Terraform idea of providers having an eventually convergent state (after running the “terraform apply” the provider should eventually produce no plan). 
+For now, we decided to add the **always_apply** parameter that always produces a Terraform plan which re-grants specified privileges per terraform apply command execution.
+It’s worth noting that the workaround doesn’t meet with the Terraform idea of providers having an eventually convergent state (after running the “terraform apply” the provider should eventually produce no plan).
 Any user relying on this principle in their CI/CD pipelines should have this in mind when using **always_apply**.
 
 ### How should we treat the on_future parameter?
-In privilege-granting resources, there’s an option to grant specific privileges on objects created in the future. 
-This raised a question of what we should do to the granted privileges when the resource with the specified **on_future** field is being removed. 
-Should we track granted privileges and revoke them or don’t track them at all? We ended up with a decision to treat the **on_future** option as a “[trigger](https://en.wikipedia.org/wiki/Database_trigger)”. 
-There were a lot of benefits that came with that assumption, and also it was already implemented in such a way, so it wasn’t a big surprise to the users already using that feature. 
+In privilege-granting resources, there’s an option to grant specific privileges on objects created in the future.
+This raised a question of what we should do to the granted privileges when the resource with the specified **on_future** field is being removed.
+Should we track granted privileges and revoke them or don’t track them at all? We ended up with a decision to treat the **on_future** option as a “[trigger](https://en.wikipedia.org/wiki/Database_trigger)”.
+There were a lot of benefits that came with that assumption, and also it was already implemented in such a way, so it wasn’t a big surprise to the users already using that feature.
 We are removing the **on_future** “trigger” on the Terraform delete operation, leaving affected grants as they were.
 
 [Documentation Reference](https://docs.snowflake.com/en/sql-reference/sql/grant-privilege#optional-parameters)
 
 ### Common identifier misuses
-A big portion of the issues regarding grants was identifier-related (missing quotes, identifiers with special characters, etc.). 
-To partially resolve this issue, we introduced better validation on the schema level for most problematic identifier fields. 
-Some of the fields couldn’t be validated, because they are multipurpose. 
-Sometimes they expect account-level objects (e.g. database) and sometimes schema-level objects (e.g. table). 
-Even though not all of the fields are using this validation method, we don’t see those kinds of issues anymore, 
+A big portion of the issues regarding grants was identifier-related (missing quotes, identifiers with special characters, etc.).
+To partially resolve this issue, we introduced better validation on the schema level for most problematic identifier fields.
+Some of the fields couldn’t be validated, because they are multipurpose.
+Sometimes they expect account-level objects (e.g. database) and sometimes schema-level objects (e.g. table).
+Even though not all of the fields are using this validation method, we don’t see those kinds of issues anymore,
 indicating the better validation method and clearer error messages helped you with defining some of the grant resources.
 
 ### snowflake_grant_privileges_to_role to snowflake_grant_privileges_to_account_role
 There are two main reasons why we wanted to create a successor of **snowflake_grant_privileges_to_role** called **snowflake_grant_privileges_to_account_role**:
-- We wanted to make a clear distinction between account and database role resources (in the name of resources and fields). 
+- We wanted to make a clear distinction between account and database role resources (in the name of resources and fields).
   We are aware that there may be resources/fields which should be adjusted to follow this convention. We will be gradually changing those notifying you through [MIGRATION_GUIDE.md](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/MIGRATION_GUIDE.md).
-- We wanted to change an internal identifier used in the **snowflake_grant_privileges_to_role** to a more import-friendly alternative. 
-  To follow some level of deprecation and give users time to migrate, It was easier to create another resource with a different name and internals for the same purpose, than change the existing resource and force everyone to migrate their state. 
-  We are aware that grants are special resources and in some cases, they may be created in the count of hundreds or thousands. 
+- We wanted to change an internal identifier used in the **snowflake_grant_privileges_to_role** to a more import-friendly alternative.
+  To follow some level of deprecation and give users time to migrate, It was easier to create another resource with a different name and internals for the same purpose, than change the existing resource and force everyone to migrate their state.
+  We are aware that grants are special resources and in some cases, they may be created in the count of hundreds or thousands.
   To migrate this number of resources is not easy and should be performed gradually, and we didn’t want to block users from the latest features of the provider just because of the grant refactoring we were doing at the time.
 
 To name a few lower-priority reasons, we also had in mind that:
@@ -89,30 +98,30 @@ Granting an application role to another application role can only be performed w
 [Documentation Reference](https://docs.snowflake.com/en/sql-reference/sql/grant-application-role)
 
 ### Instance roles won’t be added to the snowflake_grants data source (for now)
-We didn’t add the **instance_role** field to the **snowflake_grants** data source, because they would require implementing a new type of identifier, which wouldn’t be that easy. 
-We decided to tackle **instance_role** identifier later because the topic of identifiers is something we would like to look into soon [after the grant redesign](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/ROADMAP.md#redesigning-grants). 
+We didn’t add the **instance_role** field to the **snowflake_grants** data source, because they would require implementing a new type of identifier, which wouldn’t be that easy.
+We decided to tackle **instance_role** identifier later because the topic of identifiers is something we would like to look into soon [after the grant redesign](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/ROADMAP.md#redesigning-grants).
 After the identifiers redesign, we will be in a much better position to add new identifier types or functionalities around them.
 
 [Identifier redesign](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/ROADMAP.md#identifiers-rework)
 
 [Documentation Reference](https://docs.snowflake.com/en/sql-reference/snowflake-db-classes)
 
 ## Grant ownership
-Granting ownership was something that we discussed a long time ago. 
-Initially, we decided not to add it and create a document backed by an analysis that would contain reasons why it wouldn’t be possible to cover some cases. 
+Granting ownership was something that we discussed a long time ago.
+Initially, we decided not to add it and create a document backed by an analysis that would contain reasons why it wouldn’t be possible to cover some cases.
 We wanted to be careful with such decisions, and that’s why we asked for your and internal feedback ([grant ownership discussion](https://github.com/Snowflake-Labs/terraform-provider-snowflake/discussions/2235)).
 
-After receiving feedback and doing a deeper analysis of certain cases, we concluded that we can and should have this resource available. 
-Soon after, we created a design document representing a proposal of the grant ownership resource schema, behavior, and edge cases to cover. 
+After receiving feedback and doing a deeper analysis of certain cases, we concluded that we can and should have this resource available.
+Soon after, we created a design document representing a proposal of the grant ownership resource schema, behavior, and edge cases to cover.
 Currently, we are working on the implementation of the [grant ownership resource](https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest/docs/resources/grant_ownership). After it is ready, we will announce it in our GitHub repository as well as threads mentioning grant ownership.
 
 ## Future topics
-Even though the grants redesign initiative is lasting longer than we initially expected, there are still things that need to be discussed or discovered. 
-There may be some unusual cases where the current version of grant resources may struggle with. 
-With a more stable project, we will be able to do more work dedicated to discovering such edge cases. 
+Even though the grants redesign initiative is lasting longer than we initially expected, there are still things that need to be discussed or discovered.
+There may be some unusual cases where the current version of grant resources may struggle with.
+With a more stable project, we will be able to do more work dedicated to discovering such edge cases.
 For now, we’re relying on you to report such cases that we later analyze, prioritize, fix, and release as soon as possible.
 As for the list of things yet to be discussed, we have:
-- Right now, there's no way to "have **enable_multiple_grants** turned off" in the new grant resources, but we are considering adding an **authoritative** flag (the name is not chosen yet) that would work oppositely to the **enable_multiple_grants**. 
+- Right now, there's no way to "have **enable_multiple_grants** turned off" in the new grant resources, but we are considering adding an **authoritative** flag (the name is not chosen yet) that would work oppositely to the **enable_multiple_grants**.
   By enabling the **authoritative** flag, any other privileges granted to the target object will be revoked, making the granting resource the only source of privileges on this object.
 - Discussion on granting **all_privileges** and **on_all** where we’ll decide how and if we would like to track changes of:
   - Added or removed privileges by Snowflake in the case of all_privileges