Feat/storage zone improvements

[fho]

tests: replace randPullZoneName(), randStorageZoneName() with 1 function

replace the randPullZoneName() and randStorageZoneName() functions that were
doing the same with a function called randResourceName()

-------------------------------------------------------------------------------
readme: mention support for storage zones

-------------------------------------------------------------------------------
tests: add testcase for immutable storagezone fields

Add a testcase that ensures changing an immutable storagezone field fails

-------------------------------------------------------------------------------
examples: add a simple storagezone resource example

-------------------------------------------------------------------------------
simplify storageZoneFromResource

storageZoneFromResource was only setting fields in
*bunny.StorageZoneUpdateOptions that changed in the resource.
Change it to set always all fields to the current values.
This is consistent with how other *FromResource functions are behaving.

The update message sent to the bunny API will contain all settings also the
current ones instead of only the changed ones.
Depending on how the bunny.net endpoint handles missing fields in JSON payloads
for update messages this could be better or worse. :-)
If it always interprets missing fields as no change is done, it causes only
unnecessary network traffic.
If it interprets missing fields as the setting should be unset/disabled, it's
better to include the whole configuration.

The bunny.net API distinguishes between missing and empty string values
for the OriginURL and Custom404FilePath fields. When submitting empty strings
for those it resulted in an error, that those fields set to invalid
values.

To handle it the helper function getOkStrPtr() is introduced. It returns nil if
the value is unset instead of an empty string.

Replacing all get<TYPE>Ptr() calls with getOk<TYPE>Ptr() might make sense and
should be investigated in a follow-up.

-------------------------------------------------------------------------------
storagezone: remove setting state to current values on failed update

It is not needed.
d.Get() only returns the proposed state, if updating fails it is not stored as
current state.

-------------------------------------------------------------------------------
storagezone: remove date_modified key

-------------------------------------------------------------------------------
storagezone: improve error message for immutable fields

- add newlines to make the message easier to read,
- make the message vars constants,

-------------------------------------------------------------------------------
storagezone: fix: creation fails

Creating a storagezone failed with the immutable attribute errors:
        * 'name' is immutable and cannot be changed from '' to 'tf-test-20220615075051824800000019'.[..]
        * 'region' is immutable and cannot be changed from '' to 'DE'. [..]

Fix it by always allowing changes in validateImmutableStringProperty if the old
value was an empty string.

-------------------------------------------------------------------------------

[fho]

@jspizziri please review if the changes look fine.
If they do I can merge them with your PR to main.

"make check testacc" succeeded locally.

[jspizziri]

@fho this is actually currently an important bit, the reason is that there are certain values that never get read out of bunny state on a get (specifically the ones referenced in revertUpdateValues). Additionally, there is validation of these properties that happens on Bunny's side which can fail. If that validation fails on an apply we need to manually revert those values back to what they were before otherwise TF gets confused.

Thats not super clear, so here's a concrete example:

1. Add custom_404_file_path = "/foo.html" to your resource
2. Run an apply (this will succeed and correctly modify that value)
3. Update custom_404_file_path = "/bar" on your resource
4. Run an apply this apply will fail due to a validation error in Bunny
5. Run a plan immediately after the failed apply and see that TF now thinks that the state is up-to-date even though it's incorrect as the path is actually /foo.html and not /bar.

To my knowledge, this is an artifact of how those properties can't be read out of Bunny state so we need to infer their state based on successful or errored responses on update.

Hopefully that makes sense. If there's a better way to handle this I'm all ears.

[jspizziri]

Another point I want to bring up. I have no idea what OriginURL does on a SZ... it doesn't show up anywhere in the UI and seems only settable via the API. I'm suspicious that it's actually a mistake. There doesn't even seem to be any URL validation on it on Bunny's side (you can pass in "hello" or anything else you like including an empty string and Bunny will say it's fine).

I suppose it's in the API so we should support it?

[jspizziri]

I'm going to merge your changes in and I'll make my modifications on top of them.

[fho]

Another point I want to bring up. I have no idea what OriginURL does on a SZ... it doesn't show up anywhere in the UI and seems only settable via the API. I'm suspicious that it's actually a mistake. There doesn't even seem to be any URL validation on it on Bunny's side (you can pass in "hello" or anything else you like including an empty string and Bunny will say it's fine).

I suppose it's in the API so we should support it?

Interesting, we can ask the bunny support if the field has any functionality. In the past they always replied very quickly.
Let me know if you contact them.
Otherwise I can do it tomorrow.

[jspizziri]

@fho good idea. I'll contact them and let you know the result.