Increase the network connection timeout and improve error message

[jakkarth]

In some instances, connecting to an existing JabRef instance may take longer
than the original 200ms timeout. Here we increase that timeout to a full
second. If it takes longer than that to connect to an existing instance,
chances are something else bad is going on.

Additionally, in a case where we attempt a ping but it fails for some reason,
but we're also unable to bind the port to listen ourselves, we give the
user a more informative error message about the potential cause of that
problem, and offer two possible solutions: figure out what other process
is already binding the port, or file a bug if that process happens to be
JabRef (since that would indicate that a 1s timeout isn't sufficient).

Fixes #8653.

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[Siphalor]

Looks good - well it isn't that much ^^

As mentioned below, I'd provide a bit more details in the changelog (with a reference to the issue).

[calixtus]

Thanks for your effort in improving JabRef user experience. Changes look good, except one small nitpick:
The message seems to be a bit too detailed. We could put the third sentence below almost every logger message...
Be aware that the Logger already provides extensive information about the class where the warning has risen etc.
I believe the first two sentences are sufficient about the port in use.

[jakkarth]

I appreciate the feedback! I wanted the message to try to cover both potential cases:

1. Some other application is already using that port, so we can't bind it
2. JabRef is already using that port, and the ping timed out even after increasing to 1s

If we remove the third sentence, we lose point number 2. I encountered this issue and the only clue I got was that JabRef couldn't bind the port, nothing about the ping failing. Without the third sentence, a future user who hits the timeout issue will face the same lack of clues that I did. Do you have a suggestion for how we could phrase the message to cover both points? Or do you think that, post change, this scenario is unlikely enough to be encountered that it's better to shorten the message at the expense of that information? I'm happy to remove it if you think that's the better course.

[calixtus]

Sentences are:

1. There was an error opening the configured network port {}.
2. Please ensure there isn't another application already using that port.
3. If you're sure an existing JabRef instance is running and using this port, and you see this message, please file a bug.

The meaning of the first part of sentence three is implicitly covered by the second. I expect the interested user who actually reads the log files to be clever enough to reach out to our support resources. ;-)

Please just remove sentence three...

[calixtus]

i think we should put that in the documentation for troubleshooting

[jakkarth]

Done :)

[koppor]

Where in the documentation can I find it? I checked https://github.com/JabRef/user-documentation/pulls, however I don't find an open (or closed) PR.

[jakkarth]

I'm not sure what we would put in the documentation, since the timeout is not configurable. I'm happy to make a PR for the documentation project, I'm just not sure what you would like me to add there?

[Siedlerchr]

Thank you very much for your first contribution @jakkarth 🥇 Hope you were not deterred by the "nitpicking" ;) We just want to make sure that messages are understandable for the end user.