Clean up siteForm from legacy

[nightnei]

Proposed Changes

While working on Add wpcom to onboarding I noticed:

1. We have a few unused properties, it seems they are from times when we had import process located inside the form for creating a site.
2. Also after the previously mentioned PR we have 2 more unused properties now

So I decided to clean it up.

I was also thinking about moving create-site-form.tsx inside modules/add-site-form, and also merging it with modules/add-site/components/create-site, but to keep this PR easy for review, I decided that it's better not to do it right now.

I was also thinking about merging create-site and create-site-form, but to make this PR easier for review, I decided not to do it. It's not something very critical, but more important to make the PR diff clearer and easier for review.

Testing Instructions

1. Run Studio
2. Create a new site
3. Assert that it was created and no errors in browser's console

[fredrikekelund]

This is just a suggestion, and it does increase the scope of this refactor, but this component deserves a refactor to reduce the props drilling even further, IMO.

The ideal scenario would be if CreateSiteForm received a features prop to determine which features to display in the form, and an onSubmit handler that receives an object with all the form values. It makes more sense for the state to live alongside the form controls than in the useAddSite hook, at the AddSite component level.

[github-actions[bot]]

📊 Performance Test Results

Comparing ebd9fe4479e9f08b300d395fa9c604e022b00be4 vs trunk

site-editor

Metric	trunk	ebd9fe4479e9f08b300d395fa9c604e022b00be4	Diff	Change
load	12468.00 ms	17227.00 ms	+4759.00 ms	🔴 38.2%

site-startup

Metric	trunk	ebd9fe4479e9f08b300d395fa9c604e022b00be4	Diff	Change
siteCreation	37057.00 ms	34982.00 ms	-2075.00 ms	🟢 -5.6%
siteStartup	15151.00 ms	14131.00 ms	-1020.00 ms	🟢 -6.7%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change

[nightnei]

This is just a suggestion, and it does increase the scope of this refactor, but this component deserves a refactor to reduce the props drilling even further, IMO. The ideal scenario would be if CreateSiteForm received a features prop to determine which features to display in the form, and an onSubmit handler that receives an object with all the form values. It makes more sense for the state to live alongside the form controls than in the useAddSite hook, at the AddSite component level.

Great idea, but let's do it later as a separate PR

[fredrikekelund]

let's do it later as a separate PR

I created STU-1099 to track this