Date Block: Ensure that fallback value is overridden if source is not registered

[ockham]

What?

If the block's datetime attribute is set, and it is bound to a Block Bindings source, ensure that the value received is indeed the one set by Block bindings -- i.e. that the fallback value is correctly overridden.

Why?

Quoting WordPress/secure-custom-fields#206 (comment):

Note that if the Date block is inserted and its datetime attribute is bound to a[ Block Bindings source], it will currently show the wrong date on the frontend. The reason is that the datetime attribute is set to the current timestamp upon insertion (the reason for this is to distinguish the block from its deprecated version, which didn't have a datetime attribute, and would instead automatically "bind" to the containing post's publish date).

However, the Date block's datetime attribute isn't listed as bindable yet. While the Date block itself contains logic to provide backwards-compatibility, that code is currently only invoked if the attribute is not set at all.

We'll probably need to amend the latter logic to accommodate for cases where the attribute is set, but to the "wrong" (i.e. fallback) value, and needs to be overridden by Block Bindings.

How?

By fixing the logic, based on an added assertion in the unit test to cover this scenario.

You can verify that the change is indeed needed to make tests pass by reverting it (e328014) and re-running tests.

Testing Instructions

Covered by automated tests.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ockham <bernhard-reiter@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[gziolo]

This problem is very hard to understand, but I understand that when the binding is set, then it will always take precedence and replace the attribute's value.