Set default values for each property of versions object

[rdwebdesign]

What does this PR aim to accomplish?

Fixes issues when versions file contains empty or null versions, to avoid an empty footer or invalid version descriptions.

If local.version is null, the old code completely hides the component version.

See:

• https://discourse.pi-hole.net/t/version-numbers-disappearing/76922
• https://discourse.pi-hole.net/t/web-interface-version-display-bug/77228

How does this PR accomplish the above?

EDIT:

Now FTL will never send an empty string. If FTL can't find a valid string it will send null.

If local.version is null, the footer code will convert it to "N/A", to avoid empty footer or invalid versions.

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code and I have tested my changes.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)
6. I have checked that another pull request for this purpose does not exist.
7. I have considered, and confirmed that this submission will be valuable to others.
8. I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
9. I give this submission freely, and claim no ownership to its content.

---

• I have read the above and my PR is ready for review. Check this box to confirm

[DL6ER]

This should be done in the API and the code here should be rewritten to not needing the immediate versions object at all

[rdwebdesign]

It's another possibility.

[rdwebdesign]

@DL6ER

Do you want to solve the issue in FTL or should I mark this PR as "ready for review"?

[DL6ER]

I already did this somewhere these days but seemingly forgot to push the branch. Will have a look for it after work.

[DL6ER]

Is this really needed? Looking into the FTL source code, this exact usecase seems to be already there. Okay, no N/A for branch but there should never be items missing. If there are no corresponding keys in the version file, FTL will/should substitute null instead, see https://github.com/pi-hole/FTL/blob/b7eb53bf32ab76546db87c6db6d7085526788d67/src/api/info.c#L825-L864

I guess what is really needed here is a small fix of the parse_line() function skipping lines without values like

CORE_BRANCH=

This will effectively avoid an empty string being returned by the API and, hence, the automatic substitution with the nulls in the code references above. See PR pi-hole/FTL#2335

[yubiuser]

Even with pi-hole/FTL#2335 we need some small tweak to avoid the empty component to disappear

[rdwebdesign]

Even with pi-hole/FTL#2335 we need some small tweak to avoid the empty component to disappear

With the new FTL branch, only the .local.version values need a default value (|| "N/A") in this branch. Maybe FTL can send "N/A" instead of null, in cases like this.

EDIT:

If local.version is null the component won't be printed on the footer.
It doesn't really matter if remote.version is null or "N/A" (it will work in both cases).

Using the new FTL branch, the API is sending:

        "web":{
            "local":{
                "branch":null,
                "version":null,
                "hash":null
            },
            "remote":{
                "version":null,
                "hash":"54e5b294"
            }
        },

We can avoid this web PR is FTL sends something like this:

        "web":{
            "local":{
                "branch":null,
                "version":"N/A",
                "hash":null
            },
            "remote":{
                "version":"N/A",
                "hash":"54e5b294"
            }
        },

[yubiuser]

[DL6ER]

I am going back and forth about this but I think it's more natural (as in: computer-friendly) for the API to consistently reply with null and then having this PR to convert that to something more human-friendly.