feat(ux): enhance media-type switching experience in RequestBodyEditor

[mathis-m]

Description

RV8qJhofWn.mp4

1. Media-Type change is now reflected within the request-body editor.
2. When clicking the new Try It Out Reset Button the request body will be reset to its initial state.
3. When the user switches the media-type in the try-out mode, the experience is as follows:
   • If the user did edit the request body the body wont be touched and only media type is updated. This is to ensure that user content is NEVER accidentally overwritten with a default value.
   • If the user did not edit the request body it is safe to be replaced by the default value of the target media-type.

Other Changes

• ExampleValueRetainer was updated to support this behavior in case of multiple examples.
• Fix cypress test that failed but could not be reproduced in browser (somehow the cypress select() function on select elements does trigger some events in case if the select option was already selected, but browser does not).

Motivation and Context

Fixes #6836
Fixes #6835
Fixes #6517

How Has This Been Tested?

in browser
added new cypress test: on reset try out mode user edited request body value should be cleared.
added new cypress test to ensure content-type switch in request body editor.
added test to ensure user edited value is not overwritten.

I added those in a new feature oriented test file. There we could add all the bug tests for user request body interactions. Perhaps this should be done in a different PR(todo issue refactor user body interactions bug tests into new feature test folder).

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

[tim-lai]

@mathis-m

I added those in a new feature oriented test file. There we could add all the bug tests for user request body interactions. Perhaps this should be done in a different PR(todo issue refactor user body interactions bug tests into new feature test folder).

Yes, I think a new PR to collect all related user request body interactions would be excellent.

[tim-lai]

@mathis-m PR merged! This is very helpful improvement! Thanks for the contribution!