feat(schematic): add generate manifest endpoint

[andrewelamb]

• fixes fds-828
• This PR adds the generateGoogleSheetManifest endpoint
• Some additional fixes

manifest_generator_contriller_impl

• Adds generateGoogleSheetManifest controller
• Adds code for generateExcelManifest endpoint, but will complete later

utils:

• Adds InavlidValueError (used for incorrect user inptus that don't violate the schema)
• handle_exceptions catches this exception and retrurns a 422 status

storage_controler_impl

• Fixes typing

tangled_tree_controler_impl

• Fixes typing

schema_controller_impl

• Fixes name of functions and types in schema_controllers

[tschaffter]

@andrewelamb

• I recommend opening PRs as Draft and mark them as ready for review once they are and pass all the checks
• It looks like this PR is including old/out-of-scope commits. You can solve this by rebasing this feature branch

[andrewelamb]

@tschaffter I'm a bit of a rebase noob. Could you elaborate on what I should do exactly?

[tschaffter]

@tschaffter I'm a bit of a rebase noob. Could you elaborate on what I should do exactly?

Caution

Rebasing means rewriting the history of a branch (more on that below). When pushing the new history to a remote (GitHub), some commits are deleted and replaced by new ones. Please don't run any of the commands listed below unless you understand what they do.

Feature branches must start from the latest version of the upstream main branch. I recommend keeping your fork's branch in sync with the upstream main branch. This means that you will never manually commit directly to your fork's main branch. Here is how I keep my fork's main branch synchronized.

git checkout main
git fetch upstream
git rebase upstream/main

Here is how you create a new feature branch when you are currently in your fork's main branch:

git checkout -b feature-branch

Your feature branch is meant to be merged to the main branch in most cases, so you want to regularly update your feature branch with the latest state of the upstream main. One way is to merge main into your feature branch, which is the preferred way in most cases.

git checkout feature-branch
git merge main

One drawback of this approach is that the commit history of your feature branch can become crowded with "Merged from main...". It's fine for a feature branch but it is discouraged for the main branch in order to keep its commit history clean.

Another way to update your feature branch is to rebase it using the branch from which you created it (usually main). Rebasing means that you are modifying the history of your feature branch from

[commits in main (as of a past date)] + [commits in your feature branch]

to

[commits in main (as of now)] + [commits in your feature branch]

After updating your main branch, you can rebase your feature branch with:

git checkout feature-branch
git rebase main

Your feature branch lives in two places: locally and remotely (GitHub). Typically, you update the remote branch with:

git checkout feature-branch
git push

If you have rebased your local branch since the last time you pushed it, git will complain because you are attempting to rewrite the history of your remote branch. If this is what you want to do, and the answer is "yes" in the context of this tutorial, then you need to force the push:

git push --force

Finally, it's fine to rebase a local branch whenever you want, especially if this branch has never been pushed to a remote (e.g. your fork on GitHub). However, you should be careful when modifying the history of a "public" branch, i.e. a branch visible to other developers who may rely on it in one way or another. By rewriting the history of a branch on GitHub, you are effectively deleting [commits in your feature branch] before creating new [commits in your feature branch] (the commits in this list will have different commit IDs).

[andrewelamb]

@linglp Have you had a chance to review this?