Close Incoming Connection ASAP

[rido-min]

We can close the incoming connection for non invoke activities

dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[39]
      Connection id "0HNLHQGJ6JS86" accepted.
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[1]
      Connection id "0HNLHQGJ6JS86" started.
info: Microsoft.Teams.Apps.TeamsBotApplication[3]
      Activity received: Type=message Id=1778775403709 ServiceUrl=https://smba.trafficmanager.net/amer/3f3d1cea-7a18-41af-872b-cfbbd5140984/ MSCV=bPuSShts/U6fY94S5jauZA.1.1.1.1412444336.1.1
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[9]
      Connection id "0HNLHQGJ6JS86" completed keep alive response.
info: Microsoft.Teams.Apps.TeamsBotApplication[0]
      Dispatching 'message' activity to route 'message/^/(\w+)(.*)$'.
info: Microsoft.Teams.Core.ConversationClient[16]
      Sending activity to https://smba.trafficmanager.net/amer/3f3d1cea-7a18-41af-872b-cfbbd5140984/v3/conversations/a%3A1ij7Mk7bnoSE8Ail2iMwWH4okEmR9RTwCDkmQf2KCweSQbjhGuIEO2Xw9Cj32Vq-rG_dzDRzC9XmQhV7QxRWP7ucqqlhIz96ugGhR65vxRtyi6B-fsi2U4siGPtkZW8ux/activities/
info: Microsoft.Teams.Apps.TeamsBotApplication[7]
      Finished processing activity: Id=1778775403709

[rajan-chari]

Nice direction here — closing the connection early for non-invoke activities is a real improvement, and the invoke path is correctly left synchronous.

Two things I wanted to raise before this comes out of draft:

Customer retry behavior — today, if a bot throws during processing, Teams sees a 500 and retries the delivery. With this change, Teams gets 200 (or whatever status is on the response at the time of CompleteAsync) and considers the message delivered regardless of what happens in DispatchAsync. That's probably fine for most bots, but I'd like us to give customers a way to preserve the current behavior if they're relying on that retry guarantee. Would an AppOptions flag make sense here, defaulting to the old behavior?

Cancellation token scope — once CompleteAsync fires, there's a chance the request-scoped cancellation token gets cancelled before DispatchAsync finishes. Have you looked at whether we need to decouple the token from the HTTP request lifetime for the background dispatch? Might be a no-op depending on where the token comes from, but wanted to flag it.

Also noticed the CompleteAsync call doesn't explicitly set a status code first — is the intent to always send 202 here, or leave it as whatever the pipeline has set by that point?