Forms system

[Defective4]

This pull request adds the forms system to the bot.
The forms can be attached to any of the bot's messages. Users can fill in a form by clicking on the button added to the message the form is attached. After doing so, the user is presented with a modal dialog containing up to 5 fields defined in the form.
Upon submission, the contents of the fields are sent to a dedicated channel (configurable per form).

Included in this PR are commands to create, manage, and customize forms.
Forms can also be configured to accept only one submission per user. This was achieved by keeping track of who had submitted the form before in the dedicated forms repository.

Below is a video showcasing how the system works, along with most of the commands:
link (the link is broken by now)

I'm aware this can be improved in some areas. I'm looking forward to your reviews!

[danthe1st]

This is my initial review which is about the model and database.

[danthe1st]

Round 2 of reviewing, FormInteractionManager, /form add-field, /form attach

[danthe1st]

With this, most of the changed files should be reviewed.

TODO for myself: check with spotbugs

[danthe1st]

This should be the last review of your initial version.
Overall, the structure is mostly good but there are quite a few things I found.
I think you could use JDA's capabilities more in some places and you are repeating yourself quite a bit between all of the subcommands. This can be refactored using a superclass for form subcommands that operate on a form. This would allow you using common handling for autocomplete, addition (the constructor in the superclass can accept FormRepository (if necessary), the description and the OptionDatas (or similar) of the subcommand) and extraction of the form-id (or form) argument and the loading of the FormData. If the FormData is present, you could call an abstract method, e.g. protected abstract execute(SlashCommandInteractionEvent event, FormData form)
This would also allow you using Optional#ifPresentOrElse for the FormData instead of Optional#get.

[danthe1st]

TODO for myself: test with native-image - there shouldn't be any issues but just in case...

[danthe1st]

Please still act on the other requested changes like unifying autocomplete.

[danthe1st]

By the way, the last build failed because of checkstyle.

[Defective4]

By the way, the last build failed because of checkstyle.

I know. I will take care of checkstyle once I'm done writing the actual code.

[Defective4]

Also, please keep in mind that even though I'm pushing new commits, I'm still not done addressing most of the issues. I have a habit of pushing immediately after committing new changes to the code.

[danthe1st]

Also, please keep in mind that even though I'm pushing new commits, I'm still not done addressing most of the issues. I have a habit of pushing immediately after committing new changes to the code.

Just comment when you think I should re-review it.

[danthe1st]

Most of these comments are fairly minor details.
Overall, it looks pretty good.

[Defective4]

Okay, I've committed changes addressing all of the new review comments, except for this one

[Defective4]

If I didn't omit anything, I've addressed all of the old issues. I reacted with 👍 to every comment I've seen. The PR should be ready for review.

[danthe1st]

Normal Testing:

• The submission channel can be a non-text channel resulting in a We couldn't receive your submission due to an error. Please contact server staff. error.
• One option to improve the /form submission-export command would be to include links to each user's submissions (since both the submission channel and the submission message IDs are known).

I don't consider these to be necessary though.

[Defective4]

Should I fix the first issue before the PR can be merged?

[danthe1st]

You can if you want to but I don't consider this to be necessary. I will do some final tests with native-image (specifically the exporting part) which can result in some necessary changes.

[danthe1st]

Also seems to work with native-image.

When attempting to attach a form to a message from a user (not the bot), the following exception occurs:

java.lang.IllegalStateException: Attemptedtoupdatemessagethatwasnotsentbythisaccount. YoucannotmodifyotherUser's messages!
atnet.dv8tion.jda.internal.entities.ReceivedMessage.checkUser(ReceivedMessage.java:200)
atnet.dv8tion.jda.internal.entities.ReceivedMessage.editMessageComponents(ReceivedMessage.java:778)
atnet.dv8tion.jda.api.entities.Message.editMessageComponents(Message.java:1076)
atnet.discordjug.javabot.systems.staff_commands.forms.commands.AttachFormSubcommand.attachFormToMessage(AttachFormSubcommand.java:151)
atnet.discordjug.javabot.systems.staff_commands.forms.commands.AttachFormSubcommand.lambda$execute$1(AttachFormSubcommand.java:118)
atnet.dv8tion.jda.api.requests.Request.lambda$onSuccess$0(Request.java:131)
atjava.base@25.0.2/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(ForkJoinTask.java:1750)
atjava.base@25.0.2/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(ForkJoinTask.java:1742)
atjava.base@25.0.2/java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(ForkJoinTask.java:1659)
atjava.base@25.0.2/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:511)
atjava.base@25.0.2/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1450)
atjava.base@25.0.2/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2019)
atjava.base@25.0.2/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)
atorg.graalvm.nativeimage.builder/com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:832)
atorg.graalvm.nativeimage.builder/com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:808)

I guess a proper error message would be better.

Other than that, I think this PR is ready to be merged.

[Defective4]

This issue should be fixed now