fix env variables for JSONCS3 public driver configuration

[wkloucek]

Description

We've fixed the environment variable config options of the jsoncs3 driver that previously
used the same environment variables as the cs3 driver.
Now the jsoncs3 driver has it's own configuration environment variables.

If you used the jsoncs3 sharing driver and explicitly set SHARING_PUBLIC_CS3_SYSTEM_USER_ID,
this PR is a breaking change for your deployment. To workaround you may set the value you had
configured in SHARING_PUBLIC_CS3_SYSTEM_USER_ID to both SHARING_PUBLIC_JSONCS3_SYSTEM_USER_ID
and SHARING_PUBLIC_JSONCS3_SYSTEM_USER_IDP.

Related Issue

• Fixes jsoncs3 config options

Motivation and Context

How Has This Been Tested?

• test environment:
• test case 1:
• test case 2:
• ...

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[ownclouders]

💥 Acceptance test localApiTests-apiSpaces-ocis failed. Further test are cancelled...

[wkloucek]

@micbar @butonic we also might wait until we drop the idp part from the storage-(users|system), so that change will no longer be breaking for the described corner case

turns out this is a breaking change for some cases, please review again

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[wkloucek]

should no longer be an breaking change with cs3org/reva#3266. Though we could remove some the IDP config options!?

[butonic]

@wkloucek the storage syetem idp is still necessary. we may want to revisit the userid & useridp after ga, though. IMO we should exchange whatever credentials are used for an internal uuid in the proxy.