Dispose fix

[iwedaz]

1. Don't dispose external resources like HttpClient. They can be injected and controlled by DI system.
2. Don't force IArangoDBClient interface inherit IDisposable. It doesn't contain anything Disposable.
3. HttpApiClientResponse is internal resource manager class

[rossmills99]

I think there's a principle that says "don't dispose stuff you don't own" and so I'm tending to agree that HttpApiTransport should not be disposing the inner HttpClient (although there are static methods used to create HttpApiTransport that do create the HttpClient themselves - grey area?).

However it's hard to know if changing the disposal behaviour might cause problems to existing code that expects it. Perhaps we can introduce some configuration that allows you to "turn off" the disposal of HttpClient. Possibly add an optional parameter for HttpApiTransport constructor:

public HttpApiTransport(HttpClient client, HttpContentType contentType, bool suppressInnerHttpClientDisposal = false)

It can default to false so it does not affect any existing client code. For convenience, we could add the same optional parameter on the static factory methods.

@DiscoPYF would such an approach seem reasonable to you?

[DiscoPYF]

Thanks @rossmills99 👍 From our discussion, I understand better where the changes are coming from in relation to dependency lifetime management with DI frameworks.

This is a good compromise. That way there is no impact for callers that currently use the existing behaviour. I find it best to minimize the amount of breaking changes if possible, even between major releases to not create too much barrier to updating.

@iwedaz Would you be ok updating the pull request or opening a new one with this alternative proposal?

[rossmills99]

Because #481 just got merged, I'm closing out this PR and associated issue as it will now be possible to prevent disposal using an optional argument in the constructor.