Loosen the "public" condition on getSSP (#36018)

<!--
Thanks for opening a PR! Your contribution is much appreciated.
In order to make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below.
Choose the right checklist for the change that you're making:
--

## Documentation / Examples

- [ ] Make sure the linting passes by running `yarn lint`
** I've made the change via GitHub UI sorry :)**

Hi, 

I think the "data must be public" condition on getSSP is not really true, and even counter-productive. Being able to statically render more content is most probably positive, in terms of perceived and real performance of the app + energy consumption. It's actually totally possible, and not even that hard thanks to middleware, to statically render custom, paid, segment-specific content (and even individual-specific content under certain conditions).

I've documented the reason for this change in a few places if you want more details:
- related PR on React: reactjs/react.dev#4566
- demo implementation and explanation on how to couple middlewares and getSSP to statically render any kind of content (including custom content): https://blog.vulcanjs.org/render-anything-statically-with-next-js-and-the-megaparam-4039e66ffde

docs/basic-features/data-fetching/get-static-props.md

@@ -20,8 +20,8 @@ You should use `getStaticProps` if:
 
 - The data required to render the page is available at build time ahead of a user’s request
 - The data comes from a headless CMS
-- The data can be publicly cached (not user-specific)
 - The page must be pre-rendered (for SEO) and be very fast — `getStaticProps` generates `HTML` and `JSON` files, both of which can be cached by a CDN for performance
+- The data can be publicly cached (not user-specific). This condition can be bypassed in certain specific situation by using a Middleware to rewrite the path.
 
 ## When does getStaticProps run