Microservice support

[levb]

Description

This PR adds NATS microservice support. See ./examples/micro-hello.c for a very simple NATS microservice implementation.

Contains:

• microservices framework that support endpoints and monitoring subjects ($SVC.PING, $SVC.INFO, $SVC.STATS, etc.)
• a simple client to use with microservices.
• examples:
  • micro-hello is a simple example
  • micro-sequence, micro-func, and micro-arithmetics are a multi-service example that calculates sum(1/func(N)).
  • micro-stats sets a custom stats handler and keeps state in the microservice.
• misc additions:
  • type microError - microservice-level errors, with a Errorf and Wrapf functions.
  • nats_marshalDuration - formats durations, go-style
  • microArgs a simple space-deparated args parser, for examples, 2/5 prefer to publically expose nats_JSON?

[kozlovic]

Welcome to the NATS C client repo ;-)

I understand that this is still a WIP, but since it will be a new addition likely part of a v3.7.0 release, I would recommend that you locally pull the updated dev branch (I just updated with the latest changes from main) and rebase your work out of that branch and update/resubmit this PR against dev instead of main branch.

I may do a v3.6.1 release (from main) soon since there have been 3 fixes since the last release.

[levb]

@kozlovic I am getting close to having most of the implementation in place. I can really use maybe not yet a thorough review, but a large-scale assessment of the approaches used, and a scan for obvious snafus.

Personally, I feel most controversial about
a) malloc-ed microErrors - they are very handy, but the concept of entrusting/burdening the client with freeing them is definitely questionable. Since microRequest_Respond frees the error, the burden is low, that's the dominant client use-case for error handling, but still...
b) I threw together a simple args parser for the example microservice. It should be replaced with something more robust as the reference point. Suggestions? Protobuf?
c) I still do not fully understand the C and go clients concurrency model. Specifically, AddEndpoint does not lock the service in go, presumably because these are startup-only, but the endpoints start immediately and may start receiving messages before other endpoints are added... still very much figuring things out.

[levb]

@kozlovic apologies for not squashing all these commits, I now set "squash-merge" as the default for PRs to avoid it going forward.

Please take a final look at this PR; there is #663 still outstanding but it's just a change in INFO/JSON, passes the tests, I think a cursory look will suffice or just leave it to @piotrpio since he knows the context.

I'd appreciate another Windows compile (on the ^^ branch?) since I still have not been able to set up a functional windows worker build.

[kozlovic]

The test test_MicroAsyncErrorHandler is causing an assert failure on Windows and I have not yet been able to figure out what the issue is. Will continue looking into that when I have some time.

[kozlovic]

LGTM. Let's merge this and I will get back to the Windows specific issue as a separate PR. Thanks!

[kozlovic]

@levb Could you please not merge yet? I am going to push a commit that fixes the issues that I found on Windows. Thanks!

[kozlovic]

@levb Ok, please review the latest commit I pushed and if it is ok with you, then feel free to merge since I already gave the LGTM for the rest.