FIX: PWA asset isn't properly restored after deleting Library folder (ISXB-853)

[timkeo]

Description

If the project's Library folder is deleted, the previously assigned Project-wide Actions asset isn't properly restored when launching Unity. The asset is still present, but it's not assigned as the current PWA asset. Re-launching Unity again seems to resolve the issue.

The problem occurs because the logic to load and set the PWA asset runs during InputSystem initialization, before the asset Library has been rebuilt, and the call to load the saved PWA asset from the EditorBuildSettings fails. To fix this, we need to run this operation again after the asset loading has finished.

Changes made

• Attempt to Load and assigns the PWA asset to Inputsystem.actions during OnPostprocessAllAssets()

Notes

I did a little bit of testing with multiple InputAction assets to verify PWA is changed when moving/copying another asset. Still a little concerned about weird edge-cases, since this operation will run whenever any asset is changed.

Checklist

Before review:

• [x] Changelog entry added.
  • Explains the change in Changed, Fixed, Added sections.
  • For API change contains an example snippet and/or migration example.
  • FogBugz ticket attached, example ([case %number%](https://issuetracker.unity3d.com/issues/...)).
  • FogBugz is marked as "Resolved" with next release version correctly set.
• [ ] Tests added/changed, if applicable.
  • Functional tests Area_CanDoX, Area_CanDoX_EvenIfYIsTheCase, Area_WhenIDoX_AndYHappens_ThisIsTheResult.
  • Performance tests.
  • Integration tests.
• [ ] Docs for new/changed API's.
  • Xmldoc cross references are set correctly.
  • Added explanation how the API works.
  • Usage code examples added.
  • The manual is updated, if needed.

During merge:

• [ ] Commit message for squash-merge is prefixed with one of the list:
  • NEW: ___.
  • FIX: ___.
  • DOCS: ___.
  • CHANGE: ___.
  • RELEASE: 1.1.0-preview.3.

[timkeo]

@Pauliusd01

Does that mean literally any asset or just input related ones?

The callback is fired at the end of every asset "import batch" and not for every asset. The callback can be noisy but I'm not too concerned about perf issues since the code to perform the asset check is fast.

My (minor) concern is around edge-cases for when the callback is fired, i.e. might try to assign the asset when we're not expecting too. Specifically, my original change cases a test failure because this assignment occurred during PlayMode (not allowed to set PWA during PlayMode). I added the if (!Application.isPlaying) to fix the failure, but it made me wonder if there could be other cases.

Worst case though, an exception is thrown and error logged to the console. Otherwise the change is safe.