Update imgs and copy to reflect new ui

docs/pricing/quotas/manage-event-stream-guide.mdx

@@ -121,7 +121,7 @@ We strongly recommend that you make subscription changes **before** the last day
 
 Rate limiting allows you to set the maximum volume of error events a project key will accept during a period of time. For example, if you have a project in production that generates a lot of noise, a rate limit allows you to set the maximum amount of data, such as “500 events per minute”. Additionally, you can create a second key for the same project for your staging environment, which is unlimited, ensuring your QA process is still untouched.
 
-In **[Project] > Settings > Client Keys (DSN)**, click "Configure", and you can create multiple DSN keys per project and assign different (or no) rate limits to each key. This will allow you to dynamically allocate keys (with varying thresholds) depending on release, environment, and so on.
+In **[Settings > Projects > [Project] > SDK Setup > Client Keys (DSN)**, click "Configure", and you can create multiple DSN keys per project and assign different (or no) rate limits to each key. This will allow you to dynamically allocate keys (with varying thresholds) depending on release, environment, and so on.
 
 ![Per DSN Key rate limits](./img/manage-event-stream-11.png)
 
@@ -133,7 +133,7 @@ While rate limiting is quite useful for managing your monthly event quota, keep
 
 A good way to set a project rate limit is by figuring out the expected event volume based on your average traffic. Here's how to do that:
 
-1. Go **[Project] > Settings > Client Keys (DSN)** and open the project DSN key configuration under by clicking "Configure".
+1. Go to **Settings > Projects > [Project] > SDK Setup > Client Keys (DSN)** and open the project DSN key configuration under by clicking "Configure".
 1. In the "KEY USAGE IN THE LAST 30 DAYS" graph, look for the highest point, or the maximum daily rate. In the example below, the maximum daily rate in the last month is less than 34K:
    ![Calculating rate limits](./img/manage-event-stream-14-new.png)
    {/*<!-- image notes: Sentry, airflow, Santry, app-frontend -->*/}
@@ -156,19 +156,21 @@ The following rules apply for error event repetition and your quota:
 
 <Include name="feature-available-for-plan-business.mdx" />
 
-If there is an irrelevant, reoccurring issue that you are unable or unwilling to resolve, you can delete and discard it from the **Issue Details** page by clicking "Delete and discard future events". This will remove the issue and event data from Sentry and filter out future matching events.
+If there is an irrelevant, reoccurring issue that you are unable or unwilling to resolve, you can archive it from the **Issue Details** page (temporarily or forever) by clicking "Archive". This will filter out future matching events.
 
-![Delete and Discard](./img/manage-event-stream-06-new.png)
+![Archive Issues](./img/manage-event-stream-06-new.png)
 
-You can find a list of deleted and discarded issues in the "Discarded Issues" tab in **[Project] > Settings > Inbound Filters**. From here, you can un-discarded any of these issues to receive future events.
+You can find a list of deleted and discarded issues in the "Discarded Issues" tab in **Settings > Projects > [Project] > Processing > Inbound Filters**. From here, you can un-discarded any of these issues to receive future events.
 
-![List of Discarded Issues](./img/manage-event-stream-07-new.png)
+You can always view your archived issues by adding `is: archived` to the search bar in the **Issues** page, and can un-archive them from there.
+
+![List of Archived Issues](./img/manage-event-stream-07-new.png)
 
 Once you've identified a set of discarded issues, it might make sense to go back to your SDK configuration and add the related errors into your `beforeSend` client-side filtering.
 
 ## Inbound Data Filters
 
-While SDK configuration requires changes to your source code and depends on your next deployment, server-side filters can be easily configured per project in the "Data Filters" section of **[Project] > Settings > Inbound Filters**.
+While SDK configuration requires changes to your source code and depends on your next deployment, server-side filters can be easily configured per project in the "Data Filters" section of **Settings > Projects > [Project] > Processing > Inbound Filters**.
 
 Once applied, you can track the filtered events (numbers and cause) using the graph provided at the top of the "Inbound Data Filters" page.
 
@@ -190,19 +192,19 @@ After these checks are processed, events and attachments that aren't dropped bas
 
 ### IP Filters
 
-If you have a rogue client, Sentry supports blocking an IP from sending data. Navigate to **[Project] > Settings > Inbound Filters** to add the IP addresses (or subnets) in the "IP Addresses" field.
+If you have a rogue client, Sentry supports blocking an IP from sending data. Navigate to **[Project] > Settings > Projects > [Project] >  Inbound Filters** to add the IP addresses (or subnets) in the "IP Addresses" field.
 
 ### Filter by Release
 
 <Include name="feature-available-for-plan-business.mdx" />
 
-If you discover a problematic release causing excessive noise, Sentry supports ignoring all events and attachments from that release. Navigate to **[Project] > Settings > Inbound Filters**, then add the release to the "Releases" field.
+If you discover a problematic release causing excessive noise, Sentry supports ignoring all events and attachments from that release. Navigate to **Settings > Projects > [Project] >  Inbound Filters** , then add the release to the "Releases" field.
 
 ### Filter by Error Message
 
 <Include name="feature-available-for-plan-business.mdx" />
 
-Sentry supports filtering out a specific or certain kind of error as well. Navigate to **[Project] > Settings > Inbound Filters**, then add the error message to the "Error Message" field.
+Sentry supports filtering out a specific or certain kind of error as well. Navigate to **Settings > Projects > [Project] >  Inbound Filters** , then add the error message to the "Error Message" field.
 
 To ensure you’re adding the correct message to the inbound filter setting, check the JSON for an event in the issue. The filter by error message setting matches the data found in the `title` field near the end of the file.
 
@@ -214,7 +216,7 @@ The SDK sample rate is not dynamic; changing it requires re-deployment. Also, ke
 
 ## SDK Filtering: beforeSend
 
-All Sentry SDKs support the `beforeSend` callback method. Once implemented, the method is invoked when the SDK captures an error event, right before sending it to your Sentry account. It receives the event object as a parameter, so you can use that to modify the event's data or drop it completely (by returning `null`) based on your custom logic and the data available on the event, like _tags_, _environment_, _release version_, _error attributes_, and so on. Note that only error and message events pass through `beforeSend`. Tansaction events have a separate method, `beforeSendTransaction`, though it's not yet supported in all SDKs. Learn more about both methods in [Filtering Events](/platform-redirect/?next=/configuration/filtering/).
+All Sentry SDKs support the `beforeSend` callback method. Once implemented, the method is invoked when the SDK captures an error event, right before sending it to your Sentry account. It receives the event object as a parameter, so you can use that to modify the event's data or drop it completely (by returning `null`) based on your custom logic and the data available on the event, like _tags_, _environment_, _release version_, _error attributes_, and so on. Note that only error and message events pass through `beforeSend`. Transaction events have a separate method, `beforeSendTransaction`, though it's not yet supported in all SDKs. Learn more about both methods in [Filtering Events](/platform-redirect/?next=/configuration/filtering/).
 
 ## SDK Configuration