Open-next v3 planning

[coryasilva]

This is a discussion to track the path to fully supporting open-next v3 #182.

Just took a look at open-next configs and the SST PR for open-next v3 and came up with the issues below.

Issues (with relative effort and impact scores)

• [Feature] Source default server code from new folder structure .open-next/server-functions/default
  • This will allow simple use of the v3 code (resolving some outstanding issues with auth.js/[email protected]
  • This is my main drive -- I have open-next v3 working now with manual builds using this package.json script. "openbuild": "open-next build&& cp -R .open-next/server-functions/default .open-next/server-function"
  • Low effort / High impact
• [Feature] Support open-next v3 cache strategy with cloudfront function and hash
  • This is improve the cache-hit ratio -- see SST impl, seems simple enough
  • Low effort / Med impact
• [Feature] Lambda@edge middleware .open-next/middleware
  • Low effort / Med impact
• [Feature] Lambda@edge API functions .open-next/functions/${key}
  • High effort / Med impact
• [Feature] Support streaming functions
  • Med effort / Med impact
• [Feature] Support splitting server functions .open-next/server-functions/${key}
  • High effort / Low impact
• [Feature] Warmer Warmer Function #133
  • Low effort / Low impact
• [Security+Performance] Server Lambda via OAC Feature Request: Support OAC between CloudFront and Lambda #217
• [Feature] Other types of compute (like ECS) Allow Different Types of Compute Other Than Lambda #110

PS: There are also some other house keeping things we may want to handle like this PR for draft mode

@clemsonfan101, @bestickley Please provide any feedback -- I took my best guess at impact (it may be biased by use case)