Change Details

This adds the check D4013 did not add yet to avoid cluttering the diffs (as quite some code needs moving). Technically, this is just moving around existing checks (one done by the checker in the standard deposit scenario) into a common module so it's reusable. Then adds the use case scenario checking that the failure case is indeed caught by the api during the new metadata deposit update case. Only one failure case is described there so the plumbing is checked. The actual exhaustiveness in checks is done in the pre-existing `check_metadata` implementation (so no need to duplicate it within the api tests). @moranegg ^ Depends on D4013

This adds the check D4013 did not add to avoid cluttering the diffs (as quite some code needs moving). Technically, this is just moving around existing checks (one done by the checker in the standard deposit scenario) into a common module so it's reusable. Then adds the use case scenario checking that the failure case is indeed caught by the api during the new metadata deposit update case. Only one failure case is described there so the plumbing is checked. The actual exhaustiveness in checks is done in the pre-existing `check_metadata` implementation (so no need to duplicate it within the api tests). @moranegg ^ Depends on D4013

This adds the check D4013 did not add yet to avoid cluttering the diffs (as quite some code needs moving). Technically, this is just moving around existing checks (one done by the checker in the standard deposit scenario) into a common module so it's reusable. Then adds the use case scenario checking that the failure case is indeed caught by the api during the new metadata deposit update case. Only one failure case is described there so the plumbing is checked. The actual exhaustiveness in checks is done in the pre-existing `check_metadata` implementation (so no need to duplicate it within the api tests). @moranegg ^ Depends on D4013