Move docs around to update application directory.

Author: markstory

develop-docs/backend/control-silo.mdx renamed to develop-docs/application/control-silo.mdx

@@ -1,5 +1,6 @@
 ---
 title: Control Silo
+sidebar_order: 30
 ---
 
 Within the Control Silo are features that allow us to provide backwards compatibility for both customer API usage, and integrations

develop-docs/backend/cross-region-replication.mdx renamed to develop-docs/application/cross-region-replication.mdx

@@ -1,5 +1,6 @@
 ---
 title: Cross Region Replication
+sidebar_order: 40
 ---
 
 Our data-model includes many relations between users and the objects they create or interact with. Eventually users are deleted, and they need to be detached from the records they created, or those records need to be destroyed. Before sentry became a multi-region application, we relied on a mixture of Django callbacks, and postgres constraints to cascade deletions. However, in a multi-region state we arent't able to rely on these anymore as Users are in [Control Silo](/architecture/#silo-modes) and many of the objects they interact with are in the various Region Silos.

develop-docs/backend/cross-region-rpc.mdx renamed to develop-docs/application/cross-region-rpc.mdx

@@ -1,5 +1,6 @@
 ---
 title: Cross Region RPC
+sidebar_order: 50
 ---
 
 When Sentry is deployed in a multi-region deployment (like sentry.io) there are many scenarios and workflows where a region silo requires information that is stored in Control Silo. Similarly there are flows where Control Silo operations need to read or mutate state stored in regions.

develop-docs/application/dynamic-sampling/index.mdx

@@ -1,7 +1,7 @@
 ---
 title: Dynamic Sampling
 description: Dynamic Sampling is a feature of the ingestion pipeline that allows Sentry to automatically adjust the amount of data retained based on the value of the data.
-sidebar_order: 50
+sidebar_order: 10
 ---
 
 From all the data received by the SDKs, Sentry is able to extract low-granularity information through metrics, while Dynamic Sampling makes the decision of whether to keep or drop data.

develop-docs/application/feedback-architecture.mdx

@@ -1,5 +1,6 @@
 ---
 title: User Feedback Architecture
+sidebar_order: 20
 ---
 
 **The goal of this doc is to give engineers an in-depth understanding of User Feedback's backend.**

develop-docs/application/sentry-vs-getsentry.mdx

@@ -1,5 +1,6 @@
 ---
 title: sentry vs. getsentry
+sidebar_order: 70
 ---
 
 You'll find numerous references to both `sentry` and `getsentry` in our documentation. Both are [Django](https://www.djangoproject.com/) apps, but `sentry` [is open](https://github.com/getsentry/sentry) and `getsentry` is closed. What's in which?