Nuke the proxy targets

[PaulRBerg]

The PR that implements this issue should target the 2.2 branch because the proxy targets are already audited and we should keep them in version control just in case we need to deploy them.

• Remove all proxy targets
• Remove all scripts associated with proxy targets
• Remove all tests associated with proxy targets

[andreivladbrg]

branch because the proxy targets are already audited

why does it matter if they are audited or not? for example, the Archive and the Proxy Plugin are also audited, but we won't keep them as they are not relevant to 2.1 neither are the targets.

we should keep them in version control just in case we need to deploy them.

hmm, don't think we should keep them. we can always use git history (checkout to a specific commit) if there's an actual need to deploy them.

the problem with keeping them in the repo (on the main branch) is that we won't have documentation for them, or any explanation in the README on why they exist - the point is that they would cause more harm - and based on the feedback received from users, we should have them synced (docs and main).

also, i think we both agree that we should not release the NPM package with them, right?

i suggest we remove them for 2.1 to avert questions about them. questions like "why do you have them?" "the UI doesn't say we use a proxy," "why aren't they documented?" etc. answering a high volume of questions like these would be more time-consuming than checking out to a specific commit to deploy them, if we ever need them (but we don't even know if we will ever need them again).

[PaulRBerg]

good points, let's remove them

[razgraf]

If the intention is for integrators to use the latest Periphery v2.1 contracts natively (no proxy), removing the targets should be the way to go.

One important thing here is keeping historical references to v2.0 inside out documentation, given:

1. the app will still support management of v2.0 streams (e.g. the Allowance Target)
2. integrators may have already worked with v2.0 so they should be able to find the targets and ensure backwards compatibility

I'm mentioning this for posterity as I believe this final caveat is already addressed by @andreivladbrg's idea around a nested deployment-addresses documentation. At the same time, we could move the pages addressing v2.0 targets into a "deprecated" section, just so we can keep linking to them (e.g. offer a short explainer/changelog between versions in the docs and add references to those pages).

P.S. I know this is more relevant to v2-docs but it felt important to also have it part of this discussion.

[PaulRBerg]

One important thing here is keeping historical references to v2.0 inside out documentation

We can just share a historical deployment URL from Vercel

[andreivladbrg]

Addressed in 6362f22