Merge connection and driver, custom Gson instances, support for GeoJson, and more

[DamianKocher]

Changes in this pull request:

Add SurrealConnectionSettings

In the public branch, the only way to create a SurrealWebSocketConnection is to call it's constructor. As new (optional) features are introduced to Surrealdb.java, SurrealWebSocketConnection's constructor count will grow. To mitigate this, I've introduced a settings container. It's immutable with a builder instantiation pattern, so it can have sane defaults with the flexibility to customize every aspect of the connection.

Along with this, I've also added a static SurrealConnection create(SurrealConnectionSettings) method to SurrealConnection. This currently returns a new SurrealWebSocketConnection, but in the future it could return something else. I think making a change like this early in this libraries life will be a benefit in the long run.

Allow custom Gson instances

Users of the library might want to give Surreal a Gson instance with their own type adapters to use for (de)serialization. I've added some tests to make sure this doesn't break anything. If I've missed anything, please let me know.

Make models immutable

This is a pretty simple change. Making models immutable allows them to be thread safe which is a benefit for the async driver. I don't see much downside in changing this. If someone really want's to modify their data we can just add a Lombok with annotation.

More documentation

I've documented everything I believe I know about Surreal. I might have made some incorrect assumptions, so let me know if anything seems wrong.

Update jUnit

I had no issues with 5.8.2, but why not stay on the latest version?

Bumped version to 0.2.0

Since there have been a lot of changes (some breaking), I've bumped the version to 0.2.0.

Include Coder966's PRs

I wanted to use the latest version of the library, so I used @Coder966's branch as a base for all these changes. That means I inadvertently included both #3 and #5, oops!
Sorry about making all these changes in a single giant PR. I got a bit caried away.

[DamianKocher]

Many things have changed since I created this PR. Most of what I outlined in my original description has remained the same. I'll quickly go over the changes before introducing the new features:

Add SurrealConnectionSettings Fundamentally SurrealConnectionSettings has remained the same. It has been renamed to SurrealClientSettings to conform to it's new purpose.

Now on to the new stuff:

Update to Java 17 SurrealDB is a cutting edge database, why shouldn't it's libraries be the same? Java 17 makes SurrealDB.java safer by sealing interfaces, and less verbose by providing significantly better Optional support. There are many more benefits to using the latest version of Java, but I don't want to bore everyone by listing them all.

Merge SurrealConnection with Surreal Driver I've merged SurrealConnection with SurrealDriver to create SurrealClient. Clients only come in one flavor (instead of sync and async like how the public branch handles it). All async methods have a sync counterpart, and vice versa.

By using some fancy interface inheritance (which is only safe due to Java 17), SurrealClients can either be unidirectional or bidirectional. This means that it would be trivially easy to implement an HTTP based client. This PR does not include any unidirectional implementations since it's already massive. If this PR is accepted, I'll get to work on one!

GeoJson support All GeoJson types SurrealDB supports are included, along with helpful methods for manipulating them locally.

Wrapping it up

I recognize that that this PR contains many breaking changes. All breaking changes were made in an attempt to streamline interacting with SurrealDB. All future features (fluent querying API, native support for transactions, etc.) will not break the core API. In the month I've spent working on this library, I think I've created a flexible base that can be expanded upon.

Even though I've been careful to test every new features (there are 171 tests as writing this), there are most likely many issues still lurking. I'd be happy to fix any issues that are found while reviewing this PR.

Thank you.

[phughk]

Hi @DamianKocher , this is fantastic thank you very much for this! I will admit, while I agree with the individual changes, they should absolutely be split up to be handled/merged/reviewed on an individual basis. Please could you open new PRs to have these changes separated? Thanks again for going through the trouble for this - it's really good of you.

[phughk]

Closing as this is no longer being worked on