Remove v1 folder structure

[JosephMarinier]

Description:

Those tags organize the sections of the Swagger UI.

• Change Admin to Config
• Move tags definitions to the app level
• Also, remove "v1" for every tag as we don't have any other versions of the API. If one day we do, we can add v1 back.

Checklist:

You should check all boxes before the PR is ready. If a box does not apply, check it to acknowledge it.

• ISSUE NUMBER. You linked the issue number (Ex: Resolve #XXX).
• PRE-COMMIT. You ran pre-commit on all commits, or else, you
  ran pre-commit run --all-files at the end.
• USER CHANGES. The changes are added to CHANGELOG.md and the documentation, if they impact
  our users.
• DEV CHANGES.
  • Update the documentation if this PR changes how to develop/launch on the app.
  • Update the README files and our wiki for any big design decisions, if relevant.
  • Add unit tests, docstrings, typing and comments for complex sections.

[gabegma]

Good idea! For the v1, I remember in the past suggesting to remove the v1 folder (which is different than what you are doing here) and getting some pushback from the team that it was best practice to keep the v1 references. Do you know if that would apply to tags as well?

[JosephMarinier]

I don't mind removing the v1 folder.
The thing that would have been a good practice (and I guess that's where the confusion came from) would have been to have /v1 in the API paths (aligning with the current folder structure). This way, if we have to do a big breaking change in say /v1/example, we can add a /v2/example and let clients transition progressively from v1 (deprecated) to v2.
That being said, our users don't really use our API directly (unlike Toolkit for example) and we control our only client: the front end. So, I don't think this /v1 thing is necessary. And since we don't have /v1 in our API paths, the v1 folder doesn't make much sense. I will remove it.