Add HateOAS to Paginated endpoints

[singaltanmay]

This is a demo implementation of HateOAS on a single endpoint getAssembliesByTaxid().

[singaltanmay]

The application fails to start as HateOAS is missing some configuration file. I have tried searching online for how to fix it but haven't found anythin useful yet. Nevertheless it can still be seen that implementation requires creating 2 dedicated functions buildPagedResources and createPaginationLink for every endpoint. Also there is a significant amount of code inside the controller function to convert a Page into a ResponseEntity with PagedResources. All of this code is either not testable or will need to be re-implemented in the test classes. Is there a better way to design this or is this how it will have to be?

[singaltanmay]

HateOAS also needs to use Page instead of Slice because it need to know the page number of the last search result. This means the database has to run the query on the entire db instead of returning the first PAGE_SIZE number of results. Doing this could significantly hurt performance, especially when we eventually start adding hundreds or thousands of scaffolds per assembly.

[jmmut]

regarding the performance, first we have to make it work, then we will evaluate if the performance is good enough or not.

regarding the hateoas error, this one was tough. After several hours debugging, I could fix it and pushed a commit to your branch that also shows how to mock the responses. I haven't added tests that check the pagination links, tough, as I think it will be easier if we do first the endpoint of "assemblies/GCA_x/chromosomes" that will naturally lead to pagination with little test setup.

regarding buildPagedResources and createPaginationLink, I don't think there's so much stuff to do, check the taxid endpoint in my commit. PagedResourcesAssembler is a generic class that spring autowires and we can use for any entity without implementing anything. If we end up doing cross linking (put a link to chromosomes in the assembly response), then it's true we will have to build the links ourselves, but that's for another PR; for pagination links there's barely anything we have to do.

Regarding testing, a dummy mockup like the one I did is enough for most tests (unrelated to pagination). If we want to add a single test to check that the pagination links are correct, then, yes, the mock will need to be a bit more polished, but again, that will be easier to do with "assemblies/GCA_x/chromosomes", so I suggest working on that before testing hateoas pagination links.