[#MSOSDU-37919] - delete record versions using 'from' version

Description

• Issue Reference: #217
• Purge Record Versions API to clean the older record version paths.
• current enhancement scope implementation is based on the from parameter. Refer Discussions
• Code enhancement includes Parameter precedence between versionIds, limit & from

Changes in:

• Core (Common code)
• GCP
• Azure
• AWS
• IBM

Dev Checklist:

• Added Unit Tests, for new code changes.
• Added Integration Tests
• Existing Tests pass
• Verified functionality locally
• Self Reviewed my code for formatting and complex business logic.

changed milestone to %M24 - Release 0.27

added Common Code MREnhancement labels

assigned to @thulasi_dass

changed the description

added 1 commit

• ead4ea51 - - update from version datatype for optional scenario

Compare with previous version

added 1 commit

• 54c92fcb - include validation scenarios w.r.t 'from' version parameter

Compare with previous version

added 1 commit

• a88fbfe9 - Update NOTICE

Compare with previous version

marked this merge request as ready

requested review from @thulasi_dass

requested review from @chad, @nthakur, and @Rustam_Lotsmanenko and removed review request for @thulasi_dass

added 1 commit

• b4347f6f - address review comments

Compare with previous version

added 1 commit

• 54979c51 - address review comments

Compare with previous version

added 1 commit

• 41eac330 - - integration tests for bad request scenarios for 'versionIds, limit & from` version parameter

Compare with previous version

approved this merge request

approved this merge request

resolved all threads

Hi @thulasi_dass , seems like core-test pipeline is failing. Could we help take a look ? I think we need to try to get familiar with debugging the issue as this will be our formal policy soon. Would be great if we can start getting used to the access, etc.

My thoughts: It will be good to manage the core-test fixes similar to the spring migration activity distributed & prioritized across CSP and handled as separate work.

cc: @ajojohnk

failures are the same as in master, I'm trying to keep track of them:

[ERROR]   TestRecordAccessAuthorization.should_receiveHttp403_when_userIsNotAuthorizedToUpdateARecord:69->RecordAccessAuthorizationTests.should_receiveHttp403_when_userIsNotAuthorizedToUpdateARecord:123->RecordAccessAuthorizationTests.assertNotAuthorized:166 expected:<403> but was:<201>
[ERROR] Errors: 
[ERROR]   TestRecordAccessAuthorization>RecordAccessAuthorizationTests.should_receiveHttp403_when_userIsNotAuthorizedToGetSpecificVersionOfARecord:81 » NullPointer Cannot invoke "com.google.gson.JsonElement.getAsJsonArray()" because the return value of "com.google.gson.JsonObject.get(String)" is null
[ERROR] Tests run: 108, Failures: 13, Errors: 1, Skipped: 1

So I believe we're safe to proceed with changes if failures are the same.

Btw, the idea of managing tasks to fix the Community Environment in a similar way to migration tasks is worth considering. It could be used in the current stage to allocate resources for fixing the environment, and later as an ongoing support task, so we can have a developer who will be responsible for ensuring environment stability.