Add 200 code for import APIs

[nathannfan]

Import was returning 201 when this swagger was updated to return 201, and SDK tests were passing.

Import just returned 200 and caused SDK tests to fail, so leaving both 200 and 201 documented.

PR information

• The title of the PR is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
• Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
• If applicable, the PR references the bug/issue that it fixes.
• Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

• I have read the contribution guidelines.
• My spec meets the review criteria:
  • The spec conforms to the Swagger 2.0 specification.
  • The spec follows the guidelines described in the Swagger checklist document.
  • Validation tools were run on swagger spec(s) and have all been fixed in this PR.

[jaredmoo]

LGTM

[veronicagg]

@nathannfan based on your comment, it appears this is addressing a bug in the swagger, as the service is returning 200. Was the service changed (breaking change?) or just missed before?
Change itself looks good.

[nathannfan]

@veronicagg I'm not sure.

Context: Import operations can use SAS key or Storage Key. The reason I changed the response code to 201 in a previous commit was that the service was returning 201 for import operations using SAS key, and my SDK tests were failing. Now Johan is getting 200 when running his own tests.

I have a suspicion that the service is returning 201 for SAS key and 200 for using Storage key, but I haven't verified. I'd be happy to investigate.

[veronicagg]

@nathannfan I see, my question about change in behavior is mostly to know if I should label this change as a potential sdk breaking change, or it's more like a bug fix because it never worked.
Also, would a customer consuming the API care about what's returned? if so, should this be documented in the description it ends up in the documentation?

[nathannfan]

@veronicagg I've figured out what happened. It is a bug fix. Looks like importing a bacpac to create a new database returns 200, and importing a bacpac into an existing database returns 201, the opposite of what I had expected.

When I first added Import/Export, I had originally added 201 to the Import create database and 200 to Import update database, and both sdk tests passed, so I took that to mean my swagger was accurate. Later on, I happened to notice that update database was actually getting 201 back, but didn't think to check whether create database was getting 200 back, again because the tests continued to pass.

[veronicagg]

Change looks good, thanks! I'm a little curious on the statement "tests continue to pass" are you adding new tests somewhere so this would not regress in the future?

[AutorestCI]

No modification for NodeJS

[AutorestCI]

Azure/azure-sdk-for-python#1123

[AutorestCI]

Azure/azure-sdk-for-ruby#769