fix!: make useCdn use true by default

[stipsan]

Why true is better

Seeing unexpected stale content is a far better problem to have than a surprise overage bill 😅
This is a follow up to this discussion.

Also worth noting that one of the historical reasons why useCdn: false have been the default were the limitation the client had prior to v3: https://www.sanity.io/help/js-client-cdn-configuration#:~:text=subscribing%20to%20changes).-,Gotcha,-Prior%20to%20v3.0.0
Now that the client have supported using token with useCdn: true for quite some time it makes sense to change the default.

This will be a breaking release

The release note will highlight this as:
BREAKING CHANGE: if you want to keep the previous behavior, add useCdn: false to your configuration.

[kmelve]

This is a neat way of preventing some of the unintended cases of hitting the API limits.

The semver change seems a bit tricky, but then again, everyone who have been using this with undefined should have seen the warning. It seems unlikely that someone are relying on the undefined behavior for business critical functionality.

That being said, what's unclear to me is how we can make sure that the developer experience for folks that use the client to fetch content for static rendering isn't getting more confusing, as well as typical onboarding scenarios, and local development feedback loops.

New users and onboarding

How will this affect developers new to the platform who are asked to publish a document and see their change in the frontend? Maybe the cache invalidation is quick enough that it's fine? Either way, we should make sure to make a note of this property in new onboarding materials.

Documentation

This release could incentivize writing better docs on how our caching actually works, including invalidation. I see the "why aren't I'm seeing my published content" quite often.

It would also be very helpful if we provided guidance on how to set this property so it works with typical static rendering where builds or frontend revalidation is triggered by a webhook. This also affect content creators who are confused by not seeing their published content. I get that it's slightly outside of this change specifically, but it does bring it into focus.

[stipsan]

To solve the general problem of stale content we could, when publishing a document, show an intermediary "yellow" state: Draft -> Pending/Propagating/Publishing -> Published.
This state can be disabled in the studio config, it's enabled by default. A mouseover tells you if it's fully available in the API CDN yet or how long until it is (we have metrics on the timing of this).

For the static site building I think it needs better docs indeed that is tailored specifically for that. There's a lot of moving parts, ISR or no, webhooks or no, etc.

[runeb]

Added suggested changes from @tarungangwani

Approved offline

[rexxars]

While the change in and of itself looks fine, I don't agree that this shouldn't be considered a breaking change. People may have just ignored the warnings on app startup, for instance. I'd vote to bump the major version.