feat: pactbuilder can be properly disposed

[scrocquesel]

When creating PactHandle with pactffi_new_pact, it need to be freed with pactffi_free_pact_handle.

I implement Disposable interface but not sure how to handle unmanaged resource with finalizer.

BTW, I see that pactffi has a dedicated method for message interactions (pactffi_new_message_pact, pactffi_free_message_pact_handle) and use them. It doesn't change the way the consumer test generate its pact file.

[adamrodger]

These FFI methods have been effectively deprecated if I remember correctly, especially from spec v4 onwards. The new model is that the single pact handle can have both sync and async interactions added to it, and that's the call that we make internally regardless of pact type (sync, async or both [in v4 onwards])

[adamrodger]

@scrocquesel Is there a particular reason that the public API needs to be disposable? I think if we're going to free the pact handle then that should be an internal concern instead of making the consumer have to worry about that, especially because there's a huge install base out there already that won't be disposing (since they currently can't 😁 ).

Once a Pact has been verified (via VerifyAsync) then we're effectively done with that handle entirely - you wouldn't want to verify the same interaction for the same pact twice, for example. That gives us a point to do the disposal of the internal pact handle to tidy up resources.

However, we'd need to make sure we added some kind of guard to ensure that verification isn't requested twice, because there's nothing we can do to force people not to do that. We follow a Typestate Pattern to try to reduce the user's ability to accidentally do something invalid, but the semantics of C# being as they are, we can't prevent verify being called twice. In Rust, we'd take ownership of the pact at that point and then we'd be certain that nobody could call it twice.

So the best we can do it keep some kind of guard flag and then throw an exception at runtime if someone tried to call verify twice. I'd call that a bug fix rather than a breaking change so we could release that in the current 4.x line, whereas making disposal a concern of the user would be a public API breaking change and need to wait for 5.x.