Use wpcc onboarding flow for account creation during oauth login by default

[lsl]

Fixes #71027

Proposed Changes

There are two issues being resolved here:

• [Bug]: Redirect destinations are not preserved after user account creation #71027 outlines how redirect_to is ignored when creating an account from the login screen as the redirect_to param gets dropped when moving to /start. Even if it was passed in it would be ignored by the /start/onboarding flow. This PR both ensures the redirect_to is passed through and that /start/account is used in place of /start/onboarding (aka /start) when a redirect_to query param is provided.
• p1697220716421119-slack-C02T4NVL4JJ discusses account creation when logging in to e.g. vaultpress via oauth. This PR routes all signups via oauth through /start/wpcc if there isn't a specific flow already defined in signupUrl

Todo:

Could use help testing

• Each oauth client flow, especially jetpack and woocommerce.com
• Jetpack connections
• Comment / like signups

Testing Instructions

Redirect to & /start/account handling:

• While logged out visit:
• http://calypso.localhost:3000/me
• You should be landed there after creating an account using the "Create a new account" button

Wpcc login paths:

• While logged out of wordpress.com visit:
• https://vaultpress.com/
• Click login
• You'll be taken to wordpress.com login screen: e.g. https://wordpress.com/log-in?client_id=930&redirect_to=https%......
• Change the wordpress.com part to calypso.localhost:3000 for testing.
• Click "Create a new account"
• You should be taken to the /start/wpcc sign up flow and ultimately logged in to vaultpress after signup.

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-84407

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-84407&env=jetpack

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~12 bytes added 📈 [gzipped])

name         parsed_size           gzip_size
entry-login       +222 B  (+0.0%)      +12 B  (+0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~22 bytes added 📈 [gzipped])

name             parsed_size           gzip_size
security              +222 B  (+0.0%)      +13 B  (+0.0%)
jetpack-connect       +222 B  (+0.0%)       +9 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~23 bytes added 📈 [gzipped])

name                          parsed_size           gzip_size
async-load-signup-steps-user       +222 B  (+0.2%)      +12 B  (+0.0%)
async-load-design-blocks           +222 B  (+0.0%)      +11 B  (+0.0%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[paulopmt1]

It's working as expected on the Calypso private site link, vaultpress.com and WooCommerce login.
Nice fix @lsl!

[DustyReagan]

I tested and added unit tests as I went. Looks good to me! Please feel free to edit the tests! 👍

[lsl]

Moved signupFlow down to here, maintaining redirectTo pass through for consistency, I can't actually see anything that uses it other than 3-4 instances in trunk that are only using it to bypass /start (they're setting signup_flow to account i.e. what we would return with the redirect_to anyway.)

[lsl]

@eoigal do you mind taking a look re the highlander comment login pathing through here?

[mdawaffe]

Worked for me testing an OAuth2 app.

This PR directs the signup through a user-only flow (that is, no site is created). The use case I'm looking at is for an app that doesn't make sense to use unless the user has at least one site, but I think that's a separate issue. Thanks for fixing!

[lsl]

The use case I'm looking at is for an app that doesn't make sense to use unless the user has at least one site, but I think that's a separate issue. Thanks for fixing!

These are the use cases I'm worried about as we'll more or less be breaking them with this change. They should be fixable by passing in a ?singup_flow=onboarding query param to the login link. The issue being that the onboarding flow doesn't respect any redirect_to's passed in along with it. (I don't think it ever did)