Saving using a record is supported by existing code. This change adds support for loading into a record, using its canonical constructor. Both standard (JDK14+) and Android desugared (SDK34+) records are supported.

Access to record metadata is done through reflection, so this code compiles on JDK8. In order to support Android, and in order to keep the reflection logic simple, no record component reflection classes and methods are used. The price is a minor limitation: records can't have a custom constructor that has the same set of parameter names and types as the canonical one.

In order to add tests with records, I added a test-jdk17 directory and a java17 maven profile. I hope I did that correctly. Is there any other required setup for this?

The two new record test classes are identical except that one uses real records (and some new java features), and the other simulates Android desugared ones. They are both based on InfluxDBResultMapperTest, with the addition of a few record-specific tests.

There is some inconsistency between saving and loading that I am conflicted about:

• On save, existing logic, which lets you choose which fields to include, applies
• On load, all fields are always loaded into, since the canonical constructor is used

On the one hand, it would be nice to always save all record fields, for consistency. On the other hand, there is value in leaving the flexibility on save, for use cases that don't care about this consistency, e.g. write-only ones. Always saving all record fields would also be a breaking change for any (unlikely) existing code using records for saving.

And this is on top of an existing inconsistency between saving and loading, which applies to both classes and records, but is more noticeable with records:

• On save, all included fields are always saved
• On load, only fields that are contained in the query result are actually loaded. All other class fields are silently ignored, while other record fields are initialized to null, which results in an exception for primitive fields.

For this one, I could:

1. prevent the exceptions by initializing such primitive fields to their zero value, or
2. silently ignore the exceptions, or
3. catch and give a more informative exception, or
4. leave as is

Fixes #964