fix: Properly handle share attributes if set to null

[juliusknorr]

The database value of share attributes can be null, for example if creating a new share through the API. I stumbled over this when creating a new share with a deck card.

Now the frontend was unable to handle such a value from the backend and no advanced settings appeared at all, furthermore setting it was also not possible.

The default for canDownload is now always assumed true as this is the case if there is no share attribute set.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[skjnldsv]

The default for canDownload is now always assumed true as this is the case if there is no share attribute set.

But is it true by default on the backend?

[skjnldsv]

aside from my comment, it makes sense

[juliusknorr]

The default for canDownload is now always assumed true as this is the case if there is no share attribute set.

But is it true by default on the backend?

When creating a new share without having attributes set, we allow download on the backend, yes.

The frontend however always sets the download attributes explicitly to true

[juliusknorr]

/compile rebase