Enabling ErrorProne and NullAway with initial fixes

[bashir2]

Description of what I changed

See #1247 for the context. This is mostly to enable ErrorProne and NullAway. These two exposed over 370 warnings. From these, less than 20 are addressed in this PR; this is still WIP.

E2E test

TESTED:

Relying on e2e/unit tests.

Checklist: I completed these to help reviewers :)

• I have read and will follow the review process.

• I am familiar with Google Style Guides for the language I have coded in.

  No? Please take some time and review Java and Python style guides.

• My IDE is configured to follow the Google code styles.

  No? Unsure? -> configure your IDE.

• I have added tests to cover my changes. (If you refactored existing code that was well tested you do not have to add tests)

• I ran mvn clean package right before creating this pull request and added all formatting changes to my commit.

• All new and existing tests passed.

• My pull request is based on the latest changes of the master branch.

  No? Unsure? -> execute command git pull --rebase upstream master

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 78.57143% with 6 lines in your changes missing coverage. Please review.

Project coverage is 51.62%. Comparing base (ea7d0fe) to head (d78594a).

Files with missing lines	Patch %	Lines
...a/com/google/fhir/analytics/FetchSearchPageFn.java	33.33%	2 Missing ⚠️
...main/java/com/google/fhir/analytics/FetchUtil.java	0.00%	1 Missing ⚠️
...com/google/fhir/analytics/JdbcConnectionPools.java	0.00%	1 Missing ⚠️
...in/java/com/google/fhir/analytics/ParquetUtil.java	95.00%	1 Missing ⚠️
...va/com/google/fhir/analytics/DebeziumListener.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1248      +/-   ##
============================================
+ Coverage     51.49%   51.62%   +0.13%     
+ Complexity      717      715       -2     
============================================
  Files            95       95              
  Lines          5909     5894      -15     
  Branches        787      782       -5     
============================================
  Hits           3043     3043              
+ Misses         2578     2562      -16     
- Partials        288      289       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[bashir2]

@chandrashekar-s I think this is ready for review (I'll remove the Maven log file from this PR later; keeping it for now to have a sample of new WARNING messages).

BTW, the e2e-test failed a few times but passed on its own here. Looking at the some of the failed tests, I think there is a race condition between the BULK_EXPORT test and the controller test. IIUC from the dep graph and FHIR-server parameters, I think both of these tests are querying http://hapi-server:8080; but the problem is that in the controller test we are testing the incremental pipeline functionality as well. So depending on whether it runs before or after BULK_EXPORT test we may get extra resources in BULK_EXPORT test, does that make sense?

[chandrashekar-s]

@chandrashekar-s I think this is ready for review (I'll remove the Maven log file from this PR later; keeping it for now to have a sample of new WARNING messages).

BTW, the e2e-test failed a few times but passed on its own here. Looking at the some of the failed tests, I think there is a race condition between the BULK_EXPORT test and the controller test. IIUC from the dep graph and FHIR-server parameters, I think both of these tests are querying http://hapi-server:8080; but the problem is that in the controller test we are testing the incremental pipeline functionality as well. So depending on whether it runs before or after BULK_EXPORT test we may get extra resources in BULK_EXPORT test, does that make sense?

I think you are right Bashir, there can be a race condition here because of parallel tests. This has to be fixed. Also, one more issue that I could think of is that 'Turning of the HAPI source server' is not made dependent on the BULK EXPORT Test and can run into issues if the server is turned off before the BULK EXPORT job completes.