Migrate library folder contents API to FastAPI

[davelopez]

I'm trying to refactor and simplify the folder_contents API as part of a different PR and then see if I can optimize the index endpoint when trying to search on folders containing a large number of elements.

I've extracted these changes that focus only on migrating the current code to FastAPI for easier review.

How to test the changes?

• This is a refactoring of components with existing test coverage.

License

• I agree to license these contributions under Galaxy's current license.
• I agree to allow the Galaxy committers to license these and all my past contributions to the core galaxy codebase under the MIT license. If this condition is an issue, uncheck and just let us know why with an e-mail to galaxy-committers@lists.galaxyproject.org.

[mvdbeek]

Let's use DecodedDatabaseIdField where we can ... it might involve some more changes deeper in the stack, but this should be worth doing.

[davelopez]

Let's use DecodedDatabaseIdField where we can ... it might involve some more changes deeper in the stack, but this should be worth doing.

Sure! Do we want to replace all EncodedDatabaseIdField with DecodedDatabaseIdField at some point? or is worth using EncodedDatabaseIdField in some situations?

[mvdbeek]

I think changing all occurrences is going to be a big project (see my stale PR #13598), but when converting or adding new routes I think we should always prefer DecodedDatabaseIdField

[nsoranzo]

I don't know/understand much of the pydantic stuff, but I'd expect to find EncodedDatabaseIdField at the API layer like here, and DecodedDatabaseIdField in services/managers/controllers. Here it looks confusing when you compare the type and description.

[davelopez]

I got a bit confused too at the beginning, that's why I kept using EncodedDatabaseIdField, but using DecodedDatabaseIdField is waaaay cleaner as Marius suggested, we can avoid any further explicit decoding down the road.
I guess we can just rename it to DatabaseIdField or something similar to reduce the confusion after we get rid of the existing EncodedDatabaseIdFields.