chore!: remove deprecated server function and overhaul c examples

[JP-Ellis]

This PR started with the intention of upgrading the version of the server in the FFI. I took the opportunity to remove deprecated functions at the same time, which then required an update of the C examples... and here we are now, with the server not upgraded (yet), but with completely overhauled C examples.

So in the end, this PR:

• Removes the deprecated server functions from the FFI
• Overhaul both consumer and provider C examples
• Integrates these examples in CI to make sure they are tested

[YOU54F]

Looks great dude

Should we have error handling for any ffi function calls which may return an error?

For future, it would be great to add different protocol types on the consumer side, multiple transports on the provider side, both main types of provider verification (via url for webhooks from a consumer pact that has been published but requires verification, or via broker consumer version selectors for regular provider ci builds).

how to setup passing in env vars for broker selectors, and filter descriptions so users can consistently setup each library ( I think that should be in the core - relates to #250 ) - It might be a bit of a mixed bag, the verifier cli supports some env vars https://github.com/pact-foundation/pact-reference/tree/master/rust/pact_verifier_cli

I have support for some in pact ruby v2, pact ruby v1 used some.

All that is an aside from this PR though, great work. ship it!

Will have to just check we do a 0.5.0 release of the FFI and make a decent release note re: breaking changes just to let people know how to switch from the deprecated function to the new one.

[JP-Ellis]

Should we have error handling for any ffi function calls which may return an error?

It's one of these things where a proper implementation should absolutely do this, but having error handling every where is also cumbersome and might detract from the main point of these. I'll make a mention of that though in the code/docs.

For future, it would be great to add different protocol types on the consumer side, multiple transports on the provider side, both main types of provider verification (via url for webhooks from a consumer pact that has been published but requires verification, or via broker consumer version selectors for regular provider ci builds).

Absolutely, but this PR already started as a detour 😅 This can be future work.

Will have to just check we do a 0.5.0 release of the FFI and make a decent release note re: breaking changes just to let people know how to switch from the deprecated function to the new one.

Yes, absolutely! I did put a not about that in the commit:

BREAKING CHANGE: The functions `pactffi_create_mock_server` and
    `pactffi_create_mock_server_for_pact` have been removed following
    their deprecation. Please use the newer
    `pactffi_create_mock_server_for_transport` function.

This can be fleshed out to explain how it should be used.

[tienvx]

Is it 'fill resp' ? I think it's something like 'frees resp'

[JP-Ellis]

I'm not sure I understand what you mean.

The example is showing that if you create a buffer with response_buffer_init, you then need to free it later with response_buffer_free. The commented out portion is just a placeholder where the user would (typically) fill the response.

[tienvx]

Sorry, I misunderstood. I thought this comment is for the line below response_buffer_free(&resp);, but it isn't.

[JP-Ellis]

Thanks Tien for the PR review! Hopefully it all made sense (though I know you're quite familiar with the FFI already 😅)