Fix flaky integration tests when running with non-h2 databases

Fix publish release bug in genie-build.yml

To fix https://github.com/Netflix/genie/actions/runs/4177182205/jobs/7238063258

Imporve delete unused files to be able to process in smaller trunks (N…

…etflix#1184)

Co-authored-by: Xiao Chen <[email protected]>

add comments to clarify the memory related field stored in DB has uni…

…t of MB, instead of Bytes

add test

Intercept 429 http error code and raise an explicit GenieClientTooMan…

…yRequestException exception (Netflix#1169)

Co-authored-by: Andrew Nguyen <[email protected]>

Intercept 429 http error code and raise an explicit GenieClientTooMan…

…yRequestException exception (Netflix#1168)

Co-authored-by: Andrew Nguyen <[email protected]>

Upgrade to Spring Boot 2.6.x

Needed to switch off of SpringFox to Spring Docs due to springfox/springfox#3955 which has been open for a long time.

Needed to pin back Flyway due to recommended version not supporting MySQL 5.7 without a license.

Remove read only from most query peristence API's

Given the unknown nature of how the system is deployed `readOnly = true` can behave in different ways.

For example with amazon aurora and the mariadb driver if you set `readOnly = true` it will send all the requests to a read
replica endpoint which is subject to lag and inconsistency. There is no serializable isolation level. While the potential
benefits here are nice it is not worth the risk of side effects both within the system codebase itself as modules are replaced
with unknown implementations or to the REST API clients who expect consistent responses (e.g. read after write from HTTP 200 responses).

Removing `readOnly = true` from all but the non-critical search API's may slow down some performance due to JPA flush and
context evaluation but the consistency gaurantees are likely worth the tradeoff for most of these queries which are point
queries anyway to index backed columns.

Fix exposing inconsistency in job status outside of persistence API

Within job launch logic there was a helper method which would query the job status and based on the returned value proceed with some logic to either update it or fall back to other logic. This works ok if all requests to the persistence service implementation go to a single cosistent backend. If, however, read only queries go to a read replica which may have lag or some other implementation entirely this breaks down without the service actually knowing why or how.

Moving the logic for this behind the persistence API and letting the launch service only act the returned job status from the source of truth api should fix this problem.