Implement generalized sorting for entity search and get requests

[jloux-brapi]

While working on optimizing the germplasm endpoint for the production server, I noticed that the data we returned never had a specified sorting.

This led to the data coming back in inconsistent ways, sometimes changing when the same requests were made, in new but unchanged builds with no data changes. Postgres tries to keep some sort of sort going but for some reason it would change. Not good for users who would like these endpoints to be idempotent.

This began my foray into creating a generalized sorting implementation for all entities, which will be applied to the production server or now to get BI up and running. For now, search requests will allow for sortBy in the top level request, where users can specify the attribute they want to sort on. If no sortBy (or sortOrder) is specified, by default the server will sort the entities being looked up in the request by the entity id ASC. The caveat is that this request will fail if invalid sortBy attributes are specified.

This implementation should be fixed to be more robust so that it handles invalid attributes well. Meaning we should fail safely when invalid attributes come in and sort by a default value. This involves creating a generalized approach that uses reflection to check if the submitted attribute actually exists on the entity. This could get more complex if users want to specify collection attributes or attributes of other entities inside the entity (or both).

We also would need to come up with a way to advertise this to our users in the specification.

What I noticed through creating the first-pass generalized implementation in the prod repo is that this is already a SortBy class that exists, however it is only utilized by the Trials and Studies entities.

The existing SortBy class has available values stored as an enum in the class that the values from requests are checked against for these entities. This type of implementation works fine, but if we want to apply a generalized sort to every entity the enum would simply be too big and cumbersome to keep track of all the attributes.

These values are advertised in the Swaggerhub here.

We would need to do something similar for a more generalized approach to have users understand which values to send.

@jloux-brapi for our internal implementation we add an extension for filtering and sorting, which even used logical OR and AND, and also attribute and variable values. Happy to discuss sometime in more detail.