Bring Method and StatusCode types from http-types into typespec

[joonas]

I was hoping to be able to get rid of the http-types crate given that it's not actively being updated and one of the dependencies of it's dependencies has an outstanding RUSTSEC advisory (RUSTSEC-2024-0384).

Since typespec and typespec_client_core are only making use of the Method and StatusCode types, I thought bringing them into the typescript crate and using them from there seemed appropriate.

Closes #1644

[joonas]

@microsoft-github-policy-service agree

[joonas]

It looks like the analyze job doesn't like the HTTP methods CHECKIN or MKACTIVITY, should the be added to a dictionary somewhere?

[heaths]

There are licensing issues that need to be addressed first. All three projects from where files were copied are dual-licensed under an MIT license so, at the very least, we need to attribute them. These also shouldn't be in the typespec crate but under typespec_client_core:http. We could move them down the stack later, but we can never move them up the stack (after GA, anyway). Better to start further down the stack, which is why typespec only has error types right now.

I'll make some changes to this as it would probably be easier, but I can start with what you have here. Thank you.

[joonas]

@heaths that sounds great, at the end of the day my main concern here is to be able to address RUSTSEC-2024-0384 as a consumer of these libraries.

[heaths]

I appreciate that, but it seems a lot of crates are unmaintained. What happens when http falls out of maintenance? We may need to consider vendoring instead. Maybe we're not there with this small change (2 types) yet, but once we hit GA we have a strict* no-breaking-changes policy.

/cc @RickWinter @JeffreyRichter @ronniegeraghty

*) Well, mostly strict. For Rust, as opposed to most of our other languages, client APIs may break due to service REST API approved breaks but we'll also shipping 1:1 crate version:service API version.

[github-actions]

Hi @joonas. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[heaths]

Replaced by #2233, which is more comprehensive and against a relatively current HEAD.