[tcgc] add SdkCookieParameter type and support @cookie in TypeSpec http lib

[tadelesh]

resolve: #1792

[azure-sdk]

All changed packages have been documented.

• ✅ @azure-tools/typespec-client-generator-core

Show changes

@azure-tools/typespec-client-generator-core - feature ✏️

add SdkCookieParameter type and support @cookie in TypeSpec http lib

[azure-sdk]

You can try these changes here

🛝 Playground	🌐 Website	📚 Next docs

[MaryGao]

Quoted @lirenhe's comment below so my understanding is TCGC would not create a cookie parameter type for now?

TCGC could throw warning and don't expose it until we get feedback from service team.

[tadelesh]

i don't think tcgc should swallow any parameter. emitter could choice whether ignore it.

[iscai-msft]

this might cause issues in consuming emitters, just because since we're adding another type here, so previous switch statements / if else checks might be affected. I'm ok with this though, we should just make sure people are aware.

[timotheeguerin]

We need to figure out what is acceptable in the future but I think a crash because you don't handle a new type is ok as long as this new type doesn't show up on existing specs. If the TypeScript build fails because of it its also a different problem from the runtime failing.
In general I think the following needs to be true when working with ts unions for us to keep adding new features:

1. adding a new type to a union shouldn't count as breaking anyone as long as:
   a. the type only show up for scenarios that weren't possible before
2. if an library TS compilation fails uptaking the new version because they don't handle the new type its a non issue, it doesn't affect costumers.
3. if the library crash because of the new type(As long as 1.a is respected) , this is not ideal but this is also an acceptable temporary state of the library until that new type is either handled or explicitly made an error/warning and dropped.

[tadelesh]

agree. i'll let all language emitter's dev to confirm this change.