[REST server]Use framework name as job name

[Gerhut]

Closes #2439

This is a (theoretical) compatible API change, includes:

Deprecated /user/:user/jobs-family APIs

Rewrite them to /jobs/:user~:jobname-family.

*: If a namespace is already provided in job name, the :user param will be ignored, this is for e2e compatibility: a job created by POST /user/:user/jobs with un-namespaced job name would be able to retrieved by the following ways:

1. GET /user/:user/jobs/:jobname: client may hard coded the job name.
2. GET /user/:user/jobs/:user~:jobname: client may retrieve the job name from creating response.
3. GET /jobs/:user~:jobname: the new recommended way.

Rewrite /user/:user/jobs as /jobs?username=:user

Including GET and POST requests.

The POST one is newly added for distinguish with legacy (pre-0.7.0) POST /jobs API

• If POST /jobs with un-namespaced job name is called, the legacy (pre-0.7.0) job without namespace will be created. This is the compatible way to create a legacy job and have no change.
• If POST /jobs?username=:user with un-namespaced job name is called, the modern job :user~:jobname will be created, which is rewritten from POST /user/:user/jobs for compatibility with current version.
• If POST /jobs with namespaced job name is called, the modern job :jobname will be created, which is the recommended way.
• If POST /jobs?username=:user with namespaced job name is called, the user query is ignored, see *

Rewrite /user/:user/jobs/:job as /jobs/:user~:job

Including GET, PUT, DELETE (undocumented API)

Rewrite /user/:user1/jobs/:user2~:job as /jobs/:user2~:job

Including GET, PUT, DELETE (undocumented API), See *

Rewrite /user/:user/jobs/:job/* as /jobs/:user~:job/*

Including GET, PUT

Rewrite /user/:user1/jobs/:user2~:job/* as /jobs/:user2~:job/*

Including GET, PUT, See *

When requested job name contains namespace, REST server will request launcher with UserName header

There will be no namespace-wiper in the job responses

Previously, if the job name includes "~", to compatible with pre-0.7.0 legacy job, the namespace will be wiped, which makes the job name in rest-server / webportal differs with other services, now it will not be wiped automatically.

[coveralls]

Coverage increased (+0.1%) to 53.431% when pulling 8e08935 on qixcheng/rest-server/framework-name-as-job-name into b386136 on master.

[scarlett2018]

@Gerhut - is there any impact to client side like NNI and VS code extension?

[Gerhut]

@Gerhut - is there any impact to client side like NNI and VS code extension?

Theoretically, all API changes are design to be compatible with current version as well as pre-0.7.0 version

[SparkSnail]

Does PUT method of user/:user/jobs/:jobName/executionType still works?

[scarlett2018]

@Gerhut - is there any impact to client side like NNI and VS code extension?

Theoretically, all API changes are design to be compatible with current version as well as pre-0.7.0 version

@Gerhut Sounds good, I just created an issue for adding few test cases for current client dependency scenarios. #2616 To make sure any changes we made had been evaluated by these test cases before release.

@yds05 @sunqinzheng @sotetsuk - need your helps to outlist all the test cases that are impacting your integration, thanks.

[Gerhut]

Does PUT method of user/:user/jobs/:jobName/executionType still works?

Sure, it will be rewritten as /jobs/:user~:jobName/executionType and act as it was

You could view the test case of this PR and found that few changes.

[sotetsuk]

I'll check the dependency to my client (https://github.com/sotetsuk/paicli) in this weekend.
But there is no need to wait my response. I'll fix soon after the release if there is a problem. Thanks.