Stepper: Added FlowProgress component to stepper

[nelsonec87]

Changes proposed in this Pull Request

• Added a new component, FlowProgress, that shows information like "Step 2 of 10".

Testing instructions

• If you want to show the FlowProgress in a step you should add a new prop to StepContainer:

...
const stepProgress = { flowLength: 10, currentStep: 4 };
...

<StepContainer
   ...
   stepProgress={ stepProgress }
   ...
/>

In this example the values are hard-coded, but the idea is to store this information in the ONBOARD_STORE, so it's manageable from the flow configuration instead on the step (since the step may be used in different flows).
The store changes are on a different PR.

Related to #63355

[github-actions]

Calypso Live (direct link)

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

Jetpack Cloud live (direct link)

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

[matticbot]

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

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

name           parsed_size           gzip_size
entry-stepper       +301 B  (+0.0%)      +97 B  (+0.0%)

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

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.

[andres-blanco]

I was looking at this other PR that implements this feature and I find it strange that the data management is not done as part of this PR. Maybe we should add a key prop so that the store can handle many different FlowProgress components?

We could have only one selector that receives a key as parameter and returns the specific count for that key.

[nelsonec87]

I was looking at this other PR that implements this feature and I find it strange that the data management is not done as part of this PR. Maybe we should add a key prop so that the store can handle many different FlowProgress components?

We could have only one selector that receives a key as parameter and returns the specific count for that key.

I just created a separate PR for the sake of having the smallest self-contained PR, and in this case the step progress can technically be used without the store part. And we could be easier to review.

When you say a 'key', do you mean in the data management side, right? Like we pass the siteId for most SITE_STORE stuff?
I thought about it, but I didn't see the need for it. Did I get your comment right?

[andres-blanco]

LGTM! Just verify why the tests are failing to be sure if it's safe to merge.

[a8ci18n]

This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/7307319

Thank you @nelsonec87 for including a screenshot in the description! This is really helpful for our translators.