remove job configuration in jobInstance to enable casl authorization

[sofyalaski]

Description

Since we decided to not store the whole configuration in the jobInstance, the casl rules needed to be rewritten. Now the function for instance access accepts two arguments, the second being the object of jobConfig class, based on which rules are rewritten.

Motivation

Not storing the full job configuration in the job Instance. Job configuration is extracted based on the type of the job from the currently loaded configuration.

Fixes:

Passing API tests with mocha

Changes:

• I cherry-picked the commits I did on master branch to split casl into more granular parts.
• Casl rules for job instance authorization now have even more if statements because the conditioning on authorization value was previously done based on configuration being a class member. Now it's not, so we needed other mechanisms.
• AuthOp is renamed backed to Action (Spencer agreed to that here Jobs migration: define authorization model #620 (comment))
• Also this Action/AuthOp enum contained a value "JobDeleteAny" which I commented out, since it's not needed in the logic. Only users in the DeleteJobsGroup can delete jobs and criteria for instances do not exist ( I actually implemented it in one of the commits, but it was redundant as it would allow users in this group delete any instance - same as endpoint access, so I removed it again)
• In sample authorization tests I changed some of the expected test outcomes to the newer version (401 error instead of 403 mainly)

Tests included

• Included for each change/fix?
• Passing? (Merge will not be approved unless this is checked)

Documentation

• swagger documentation updated [required]
• official documentation updated [nice-to-have]

[sofyalaski]

Despina, I can also make a PR straight to release-jobs if you prefer. merging might be a pain..

[despadam]

Great job @sofyalaski 👏 My only comment is the following:

I tried running the mocha tests on this branch and I got these results:

  1067 passing (7m)
  6 pending
  9 failing

  1) 0300: DatasetAuthorization: Test access to dataset
       0502: add a new raw dataset with specified pid as Admin:
     Error: expected 201 "Created", got 400 "Bad Request"

  2) 0300: DatasetAuthorization: Test access to dataset
       0530: add a new raw dataset with specified pid and different owner group as Admin:
     Error: expected 201 "Created", got 400 "Bad Request"

  3) 0300: DatasetAuthorization: Test access to dataset
       0702: add a new raw dataset with specified pid as User 2 which belongs to a create dataset with pid group:
     Error: expected 201 "Created", got 400 "Bad Request"

  4) 0300: DatasetAuthorization: Test access to dataset
       0802: add a new raw dataset with specified pid as User 3 which belongs to a create dataset privileged group:
     Error: expected 201 "Created", got 400 "Bad Request"

  5) 0300: DatasetAuthorization: Test access to dataset
       0830: add a new raw dataset with specified pid and different owner group as User 3 which belongs to a create dataset privileged group:
     Error: expected 201 "Created", got 400 "Bad Request"

  6) 0700: DerivedDataset: Derived Datasets
       0130: should be able to add new derived dataset with explicit pid:
     Error: expected 201 "Created", got 400 "Bad Request"

  7) 0700: DerivedDataset: Derived Datasets
       0150: should be able to add new derived dataset with group that is part of allowed groups and correct explicit PID:
     Error: expected 201 "Created", got 400 "Bad Request"

  8) 0700: DerivedDataset: Derived Datasets
       0240: should delete a derived dataset with explicit PID:
     Error: expected 200 "OK", got 404 "Not Found"

  9) 1400: ProposalAuthorization: Test access to proposal
       0040: cannot access proposal as unauthenticated user:
     Error: expected 401 "Unauthorized", got 403 "Forbidden"

Then I wanted to compare with the tests on master and noticed that errors 1 - 8 are the same, but error 9 is a new one. I suspect error 9 is caused by the changes in test/TestData.js. Regarding errors 1 - 8, do we still want to allow for failing tests on master branch?

[sofyalaski]

Hello Despina, yes, proposals error is new.. I think this was something that propagated from my cherry-picking a commit. I fixed the return code for that test to be same as a value in master