Fix PHPStan error with wp_insert_user() which causes it to hang

[westonruter]

The commits in this PR were cherry-picked from #10419 for Core-61175.

See #10419 (comment):

I also got to the bottom of the issue with wp_insert_user() causing PHPStan to hang. Or at least, I think I did. The issue is that PHPStan couldn't figure out what $userdata's type was. So in 77d9403...512e368 I've ensured that $userdata always is a string, and I went the extra mile to ensure back-compat for passing in unexpected values to that function.

Trac ticket: https://core.trac.wordpress.org/ticket/64238

Use of AI Tools

n/a

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props westonruter, justlevine, peterwilsoncc.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[westonruter]

@peterwilsoncc Hey! I'm requesting your review because this appears to have been related to your commit in r60650.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[peterwilsoncc]

@westonruter These changes look fine to me and I'm happy enough for them to go in.

My one nagging concern is about how real and issue this is, and whether the code is being added for the benefit of tooling over users.

I guess my question comes down to, are we better off changing @param array|object|WP_User $userdata to @param array|stdClass|WP_User $userdata?

That said, I'm happy to use your judgement. I have verified that prevents phpstan from hanging.

[westonruter]

@peterwilsoncc thank you. My guess is that 99.99999% of the time, a array|stdClass|WP_User is passed in. But I can imagine someone wanting to pass in an array-like object for the sake of lazy-loading. So I wanted to be sure this didn't break anything.

It's also true that PHPStan probably shouldn't be struggling so hard here. But I still think this is an overall improvement since it improves type safety, ensuring that down the road the function is guaranteed to always be working with an array as it expects to be.

[westonruter]

Committed in r61656 (297771e).