Logging changes + new user with forced random password

[kontza]

Hi,

What do you say to this? I changed print statements to use logging via Rich package.

Also, new user creation does not use the changeMe password as my Gitlab 17 did not accept that being too simple, so I added the force_random_password flag to the new user creation call.

[swingbit]

@kontza Thank you for this.

The reason I'm not merging it yet is that the PR contains a lot of writing style changes mixed to the actual changes, which I don't want to pull in. Also, I specifically wanted to avoid relying on existing modules for interacting with Gitlab, just API calls.

So, I'll apply your changes, but I need to find the time to cherry-pick from them.

[kontza]

Hi, again.

I just managed to finally migrate our big Jira project with its 3000 issues over to our self-hosted Gitlab instance. Related to that, I made a few further changes to jira2gitlab:

• If IMPORT_AUTO_CONTINUE is true, do not prompt user for continuing when the import status pickle already exists. Just use the existing file. I had a problem where migration would semi-randomly die on a timeout error when communicating with Gitlab. But as the script could now correctly detect issues not migrated, I made a shell script to run the migration script a thousand times (finally all issues were migrated). And that shell script required the user prompt not to be shown.
• If HASH_DETECTION is False, use Jira issue's updated field for change detection. In my case, for some reason, the hash calculation always ended up re-migrating all issues. Date based approach detected nicely those Jira issues that had not been migrated yet.
• If there is a file, jira-issues.json, use that for Jira issue source, and do not download issues from the server. I had 3000 tickets on the Jira server and each migration attempt started with a five minute wait on downloading those issues.

And a very big thank you for making this script!