Previously, if a `SubmittingPlayer` instance deemed it okay to proceed
with gameplay despite submission failure, it would silently log all
errors and proceed, but the score would still not be submitted. This
feels a bit anti-user in the cases wherein something is genuinely wrong
with either the client or web, so things like token verification
failures or API failures are now shown as notifications to give the user
an indication that something went wrong at all.
Selected cases (non-user-playable mod, logged out, beatmap is not
online) are still logged silently because those are either known and
expected, or someone is messing with things.
Right now, the client does nothing to ensure a beatmap is in a valid
state before requesting to submit a score. There is further work to be
done client-side so it is more aware of this state (already handled for
playlists, but not for the solo gameplay loop), but the solution I have
in mind for that is a bit more involved.
This is not used server-side yet, but I want to get this sending so we
can start using it for some very basic validation.
Will resolve the basic portion of #11922 after implemented server-side.
These share too much yet have very different constructor signatures and
property exposure. Just a clean-up pass as I begin to look at replay
submission.
