Use pooled StringBuilder to reduce allocations when adding response cookies

[dougbu]

• ResponseCookies.Append() allocates lots, big lots #561
• new SetCookieHeaderValue.AppendToStringBuilder() method; avoids per-call StringBuilder allocation
• ResponseCookies uses ObjectPool<StringBuilder> that ResponseCookiesFeature provides
• ResponseCookiesFeature creates an ObjectPoolProvider instance if none in DI
• IResponseCookiesFeature exposes int properties supporting middleware overrides of the pool policy

nit: Add some doc comments

[dougbu]

Note this is based on #589

/cc @davidfowl here's one idea for addressing #561. This does not require any changes in other repos. Middleware can adjust the pool policies but I doubt our middleware needs that.

Details

Looking more closely at the repos that add cookies, I suspect most, even Antiforgery, will always add cookie values shorter than the 4k default maximum size used here. In particular, the Antiforgery cookie token is shorter than I thought because it does not contain claims and most other token values are short identifiers. In addition CookieOptions shouldn't make cookie values significantly longer.

Probably worth measuring allocations when using the TwitterMiddleware. The TwitterHandler uses a RequestToken containing a fair amount of information. But it appears that cookie is a session cookie. (So making the test realistic may be difficult 😈)

[davidfowl]

This still assumes something is coming from services no?

[dougbu]

This still assumes something is coming from services no?

No. If an ObjectPoolProvider is a registered service, the feature uses it. But it'll fall back to creating its own DefaultObjectPoolProvider otherwise.

[Tratcher]

👎 This is an implementation detail, not a generic feature property.

[dougbu]

Closing. Will reopen against dev.