Handle empty strings in config values

[tobio]

Description

Empty strings are treated as null in the underlying API. Mimic that behaviour on the provider schema.

Related Issues

Fixes #698

Motivation and Context

How Has This Been Tested?

Unit testing, manually.

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (improves code quality but has no user-facing effect)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation

Readiness Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[dimuon]

LGTM 👍

Changelog is needed.

It seems we face with the similar issue for different fields when an empty value can be represented by either null or empty value. Still we came up with different solutions, e.g. as far as I can recall, for some fields we check the value specified in the config/plan and fallback to it in the reader, while here we change the next planned value to null in plan modifier.
Both approaches seem valid but maybe it makes sense to stick to the same way for different fields, also maybe we can come up with a general solution.
Anyway please feel free to merge the PR.

[syepes]

+1

[Zawadidone]

+1, @tobio when will this PR be reviewed and merged? It could solve an issue that randomly occurs when the version is an empty string (#698 (comment)).

[tobio]

@Zawadidone sorry for leaving this one sitting around. I'm wary there's still issues with the overall config attribute and have wanted to do some more testing on this but it's unfortunately been dropped for a little while.

I'll try and refresh this one and assuming it's not introducing another bug get it merged in the next few weeks.

[dotspec]

Is there any hope of seeing this get merged? I spent the better part of yesterday fighting this exact bug with a module I've been working on and it'd be nice to not have to build in a work around.