Feature/#173 client name

[hemidactylus]

Closes #173

This proposes simplification and the infrastructure, at the "request functions layer", for optional management of client name and client version by the astrapy classes.

By client_name and client_version it is meant something such as "langchain" and "0.2.0", optionally set by the code that uses astrapy (in a way TBD). This would make for better usage statistics.

• The APIRequestHandler classes have gone, replaced by functions
• principle: removal of all default values for params at the utils.py and api.py layers, to let the linters catch forgotten call paths. Default values used in ops.py and db.py, not below.
• a function(client_name, client_version) to generate the final user-agent string, where both args can be null
• right now, the db.py and ops.py calls always fill in with None but the infra is in place

As per API specs, it is desired that this client_name is first in a slash-separated string. Currently I went for a format, if everything provided, like "langchain/astrapy/0.7.3/0.2.0".

Open questions

How exactly should code that uses astrapy "set" or communicate this info, if it desires to? (setter methods or additional params to a lot of class methods? Both?). This is to be defined, hence this is a draft.

Please someone come up with a better naming scheme other than client_name/version. There are way too many "clients" around already. On the other hand, "user" seems not right. Caller, perhaps?

[cbornet]

Missing not ?

Suggested change

	if client_name:
	if not client_name:

[hemidactylus]

Good catch!

[hemidactylus]

I suggest this PR stops here (pure internal refactoring) and another one does the actual implementation of new API.

Besides the internal refactoring (and the final shape of the compose_user_agent function), this PR introduces a new test dependency and a specific test (with a simple example) to intercept requests and check for the user-agent - ready to be extended.

Note: the reason I went for pytest_httpserver and not pytest-httpx is that the latter requires Python 3.9+. We want to keep compatibility with 3.8.