Use shorthand nullability typings for better readability

[jnoordsij]

WHY

BEFORE - What was wrong? What was happening before this PR?

When working on #5732, I encountered some other (nullable) types that could be simplified, to improve readability.

AFTER - What is happening after this PR?

Cleaner code.

HOW

How did you achieve that, in technical terms?

Use shorthand.

Is it a breaking change?

No (or not really); only the change in RegisterUploadEvents::handle is a change in behavior, due to no longer allowing null; however explicit null passing seems unlikely and unwanted here.

How can we test the before & after?

N/A

[pxpm]

Hey @jnoordsij thanks for the contribution. 🙏

Would it be too much to ask to merge both PR's into a single one, since they address the same issue ?

If you don't have time/will to do it, let me know and I can do that, I'd rather merge this as a single PR 👍

Cheers

[jnoordsij]

I'm all fine with adding the commit here to #5732. I've deliberately split them, as #5732 now only contains essential changes that are practically identical to the previous state, just solving the deprecations.

This MR goes slightly further by actually introducing a single behavior change, and thus should arguably be handled with a little more care. Moreover, the changes are merely cosmetic and are not required to actually fix deprecation messages, like #5732.

However, if you prefer handling it all together at once, just let me know and I'll cherry-pick this onto #5732.

[pxpm]

Thanks for the clarification. 🙏

I agree then, let's merge the other PR in v6, and mark this for v7, I agree that it's unlike that anyone is using null in that parameter, but it was overlooked and to be safe we should do it in v7. We already have some BC's in internal code for uploaders in v7.

Thanks @jnoordsij 🙏

[jnoordsij]

Sounds great! I've rebased this to resolve conflicts with the new target branch.

[jnoordsij]

Rebased onto next to fix conflicts