Remove stalled stream protection from transcribestreaming

[landonxjames]

Motivation and Context

awslabs/aws-sdk-rust#1181

Checklist

• For changes to the AWS SDK, generated SDK code, or SDK runtime crates, I have created a changelog entry Markdown file in the .changelog directory, specifying "aws-sdk-rust" in the applies_to key.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• No codegen difference in the Client Test
• No codegen difference in the Server Test
• No codegen difference in the Server Test Python
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.

[aajtodd]

This is fine for now and follows existing conventions.

I think we really want to change how we structure customizations though. This removal of stalled stream protection is scattered around instead of being defined in one place. This isn't the only offender either. We should probably define it as a customization describing what it does and apply it to as many services/operations there.

e.g.

/// Disable stalled stream protection for specific operations that are not compatible
/// (e.g. where waiting for the service to respond is expected). 
class DisableStalledStreamProtection : ClientCodegenDecorator {
      private val appliesTo = setOf( ... )
}

In Kotlin (and other smithy code generators) this is pretty common (examples: common customization, service specific)

[landonxjames]

I think we really want to change how we structure customizations though. This removal of stalled stream protection is scattered around instead of being defined in one place. This isn't the only offender either. We should probably define it as a customization describing what it does and apply it to as many services/operations there.

Agree I thought of that while I was doing this, but it was the weekend and I wasn't going to spend too much time on it. I created #3835 to track this and I'll hopefully get around to it when oncall/flexible checksums/observability are all mopped up. Adding it to our tracking board as well.