Fix audio response playback for non-GET requests

[didzis]

This PR is another attempt to fix #8378 when audio playback controller point to the URL of dynamically generated content and not the actual returned content (in browser memory).

Description

The difference of this PR from the previous attempt by the issue author is that this PR checks if the request method was other than GET (and thus is compatible with the default behavior) before trying to convert returned response content to a blob URL into browser cache memory.

Motivation and Context

The problem with the default approach before this PR is that it assumes the URL points to a static resource on the remote host, but in case of dynamically generated audio content (as it usually is the case with Text-to-Speech APIs), the REST API call requires extra parameters (without such the response is invalid) and is not reasonable to be run implicitly by browser.

Fixes #8378.

How Has This Been Tested?

Tested with POST request to a TTS (Text-to-Speech) API endpoint that generates audio response dynamically on-demand depending on extra parameters (query, body content etc.).

Screenshots (if appropriate):

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.