Temp fix for no match for request bug. Fixes #9591

[adewaleo]

Temp fix for #9591.

Because NoRecordingPreparers don't record requests during resource creation, during playback they are not aware of the random name used during recording.

The fix is to use a deterministic moniker during recording and playback. This means to get the effect of randomness a user might have to manually change the resource preparer's prefix and / or name length.

Some solutions to keep resource names random during live runs:

1. add some metadata to the recordings that indicates what deterministic names should be used during playback
2. change request matching logic and ensure that each preparer of the same type has a different prefix and name_length
3. Keep traffic recordings for preparers but only use them to determine the name of the prepared resource during playback

---

This checklist is used to make sure that common guidelines for a pull request are followed.

• The PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).

• I adhere to the Command Guidelines.

[tjprescott]

If this is only supposed to apply to playback mode, then should it not be something like:

if self.is_live:
  return random_thing
else:
  return self.moniker

?

[tjprescott]

Because NoRecordingPreparers don't record requests during resource creation, during playback they are not aware of the random name used during recording.
The fix is to use a deterministic moniker during recording and playback. This means to get the effect of randomness a user might have to manually change the resource preparer's prefix and / or name length.

No. This is a regression. It would be better to completely back out the original PR than implement this.

[adewaleo]

I will close this given the comments and #9602 fixes this issue