Add equals/hashcode for Destination

[newtork]

Backlog item: https://github.com/SAP/cloud-sdk-java-backlog/issues/403

Context

• A destination can be enhanced with keyStore and trustStore properties; both of Java type KeyStore. Useful in mTLS scenarios or when having a custom root certificate for TLS/SSL.
• Java KeyStore API does not offer a custom implementation for equals and hashCode. This is why we exclude it from evaluation in the DefaultHttpDestination class.
• We primarily use hashCode to isolate destination-related cache entries, e.g. for resolving stored HttpClient instances.

Currently on main.

Destinations are evaluated as equal with same hash-code:

• Trivial case
  • Destination1(name=foo, staticHeaders={sap-client:100})
  • Destination2(name=foo, staticHeaders={sap-client:100})
• Assigned KeyStore or TrustStore
  • Destination1(name=foo, staticHeaders={sap-client:100}, keyStore={fizz})
  • Destination2(name=foo, staticHeaders={sap-client:100})
• Assigned KeyStore mixed TrustStore
  • Destination1(name=foo, staticHeaders={sap-client:100}, keyStore={fizz})
  • Destination2(name=foo, staticHeaders={sap-client:100}, trustStore={buzz})

With this PR

Destinations are evaluated as equal with same hash-code:

• Trivial case
  • Destination1(name=foo, staticHeaders={sap-client:100})
  • Destination2(name=foo, staticHeaders={sap-client:100})
• Assigned KeyStore or TrustStore
  • Destination1(name=foo, staticHeaders={sap-client:100}, keyStore={fizz})
  • Destination2(name=foo, staticHeaders={sap-client:100})
• Assigned KeyStore mixed TrustStore
  • Destination1(name=foo, staticHeaders={sap-client:100}, keyStore={fizz})
  • Destination2(name=foo, staticHeaders={sap-client:100}, trustStore={buzz})

Limitation

This behavior change only applies to KeyStore instances that have certificate based entries only.
E.g. if a KeyStore with only a secret-key would be added - it will be ignored from equals/hashCode, i.e. the previous behavior of main applies again.

[CharlesDuboisSAP]

My comments are also valid for resolveKeyStoreHashCode.

[CharlesDuboisSAP]

It will only throw when a keyStore is not initialized. The first thing in resolveCertificatesOnly should be filtering for un-initialized keystores. Or maybe in the destination itself.

[newtork]

• There is no method on KeyStore to check for "is-loaded" unfortunately.
• The existing API and behavior assumes the KeyStore in keyStore and trustStore fields are already loaded. There is no "lazy loading" or sth like that in already initialized Destination / HttpClient objects.
• I want to avoid additional logic within DefaultHttpDestination class or its super classes as far as reasonably possible, this is why I put all potential logic into this helper comparator util class.

[CharlesDuboisSAP]

What happens if a certificate is followed by "not a certificate"? Should "not a certificate" rather be ignored instead?

[newtork]

I didn't want to mix behavior:
As soon as a non-certificate based entry occurs, the logic falls back to current main behavior, i.e. ignore everything.

[CharlesDuboisSAP]

I hope those destinations are supposed to be equal:

final KeyStore keyStore = KeyStore.getInstance("JKS");
keyStore.load(null);
keyStore.setCertificateEntry("a", cert);
Destination dest = DefaultHttpDestination.builder("https://example.com").keyStore(keyStore).build();
final KeyStore keyStore2 = KeyStore.getInstance("JKS");
keyStore2.load(null);
keyStore2.setCertificateEntry("b", cert);
Destination dest2 = DefaultHttpDestination.builder("https://example.com").keyStore(keyStore2).build();
assertThat(dest).isEqualTo(dest2);

Otherwise LGTM

[MatKuhr]

I hope those destinations are supposed to be equal:

final KeyStore keyStore = KeyStore.getInstance("JKS");
keyStore.load(null);
keyStore.setCertificateEntry("a", cert);
Destination dest = DefaultHttpDestination.builder("https://example.com").keyStore(keyStore).build();
final KeyStore keyStore2 = KeyStore.getInstance("JKS");
keyStore2.load(null);
keyStore2.setCertificateEntry("b", cert);
Destination dest2 = DefaultHttpDestination.builder("https://example.com").keyStore(keyStore2).build();
assertThat(dest).isEqualTo(dest2);

Otherwise LGTM

I think this is fine, currently the aliases don't matter AFAIK. I think it wouldn't hurt to also compare the aliases, they should always be equal as well in our usage, but not super required I guess..

[newtork]

Good find, @CharlesDuboisSAP. I haven't noticed that I removed the alias comparison :/
This was indeed unintended change during my commits.

@MatKuhr is right, the aliases are not important at runtime.

However not comparing them might be add to the confusion 🤔 On the other hand adding new logic now to compare Enumeration<String> aliases (does not implement equals/hashCode natively) would add unnecessary code complexity and potential edge cases that we don't want to cover explicitly (yet).

Therefore I'll leave it as is.
Sorry future devs ;)