[Tech Spike][WS->Next Stack] Consolidate and simplify app stack

[idiom-bytes]

Problem

1. pdr-ws has been nightmarish to support, has had a lot of problems due to pdr-web + pdr-websockets requiring to be in-sync, and a lot of code is getting duplicated/fragmented against pdr-web.
2. Due to current OKR: pdr-web + pdr-websockets should be nearly-frozen for now.

I propose we take a look at the app stack so: it's more maintaneable, improves DRY violations, reduces fragmentation, makes complete app easier to deploy and ops. Right now @trizin has been helping to deploy it too... this could all be easily addressed by moving to a stack that's easier to manage.

Towards a solution:

Rather than building a pdr-fe-util lib to start addressing some of this problem... I think there is a solution to tech spike that would reduce this complexity by an order of magnitude, and increase the velocity to delivery by an order of magnitude.

Next.js is an incredibly powerful stack that should be able to reduce this problem to something incredibly simple that solves the problem.

1. Deploy next app as a UI client on vercel.
2. Deploy the same next app as a pure server/backend w/PK on prod vm.
3. All code in next UI + BE is shared in the same code base
4. Kill websocket and supporting another stack. It's now unnecessary (1)(2).

Final Outcome:

1. (1) and (2) are deployed in separate environments but share the exact same stack. PK is not shown to client. We leverage more of next.js native functionality.
2. (1) reads from (2)

DoD:

• [ ] Do simple tech spike to prove separation of Client UI + Backend PK in next
• [ ] Consolidate code across pdr-websockets and pdr-web
• [ ] Cleanup code so that the latest/greatest implementations of everything are inside 1 repo
• [ ] Building around FE + BE that requires PKs, can now happen more easily

[kdetry]

will we use websocket as the communication method, or will we use polling/intervaling with HTTP requests? (I am open to both of them, WebSockets are good but it brings some issues too)