SPARK-2341 Improve signup wizzard

[stokito]

First changes for the https://igniterealtime.atlassian.net/browse/SPARK-2341
I'll continue on this in a few months later because the current changes are already useful and will allow to users to get an account more easily so the main goal is achieved.

[Plyha]

Excellent! Is it possible to make domains taken from existing accounts on the computer? For example, as an administrator in my company, I did not want users to create accounts on the Internet.

[stokito]

I think that a proper way would be to register in LDAP by and admin and disable the Signup button with ccAccountsReg.
See org/jivesoftware/LoginDialog.java:525

Anyway, the PR doesn't make anything worth but will help for inexperienced users.

[Plyha]

What you are doing is great! But this list is difficult to maintain. I'm afraid there will be people who want to add their domains to the list, and Spark's release may not happen in the near future. I think the list should be compiled based on existing accounts, or the administrator could add his domains to the spark configuration file.

[stokito]

I don't know how exactly the Spark is used in a corporate environment.
If an admin is in control of the properties then maybe it should just register an account itself ether directly on a server or in AD.
Otherwise an intruder can register himself and start phishing as a someone from a company.
In the JIRA there is a feature request to specify an account from env (or property?). This may be a better solution if an admin wants to specify a server (or a full jid) for a user.

The list doesn't really needs to be maintained. Currently there is only three servers that I tested to work without a CAPTCHA (that is not implemented yet).
This servers are working for long time and unlikely them all to disappear in near time.

So users who don't know what is the server may easily register at least somewhere. This is level 1 of help. Level 0 would be to add a link https://xmpp.org/getting-started/#2-create-an-account as the Gajim does. I just didn't had enough time for this.

Later we can add support of CAPTCHA and uncomment other servers.
Then we may add fetching of servers from the providers.xmpp.net.

Add servers from existing accounts is a good idea. We may add this too, just not sure how it will be useful given that most users have only one account.

As another solution to autodetect the XMPP server we can check if the computer is in a domain and make a DNS request to the controller to find XMPP in the SRV records. Or just add it to the list and user may try to register there. The env LOGONSERVER shows a controller and the USERDNSDOMAIN should show a hostname of the computer

As a side improvement we can add known servers as a dropdown to autocomplete domain in the login dialog. Those servers may even not support a registration, just be popular.

As you see, that's all improvements that doesn't discard the PR itself but can be built upon it.

[Plyha]

I think the idea of ​​a computer domain + a DNS request to the controller is an excellent solution.

[stokito]

domain + a DNS request to the controller is an excellent solution.

Ok, we may try to implement this. But I don't have enough time now.

Meanwhile I added a check if a server supports registration and even added a rendering of a form.
This allows to show at least something even for a servers with a captcha like conversations.im:

[stokito]

For a comparison I checked how the registration is handled in other apps.
The Conversations.im app:
https://codeberg.org/iNPUTmice/Conversations/src/branch/master/src/main/java/eu/siacs/conversations/xmpp/XmppConnection.java#L1761

It gets the CAPTCHA image from <data>, instructions from two different sources and sets the ocr field.

Other implementations are tracked here https://invent.kde.org/melvo/xmpp-providers/-/issues/44

[stokito]

Added downloading providers, there is a simple JSON version that can be parsed without a JSON library.

[stokito]

@Plyha could you please review the PR?

I think the idea of ​​a computer domain + a DNS request to the controller is an excellent solution.

I'll do this later in a separate PR. This looks like not so difficult to implement but I need more time to investigate if the ENV variables are set on Windows.