Fixes #41 - Added Api#fetchServerSettings.

[n1k0]

Goals

The client should retrieve server settings from the /vX endpoint; for now, the only setting we need is the batch_limit one.

Tasks

• On each outgoing HTTP request, first ensure we already have retrieved the settings information;
• If we haven't yet, request that information from the /vX endpoint, then store the settings in a local Api property;
• On subsequent requests, reuse the cached settings property to avoid hammering the server for no reason;
• Write an integration test.

Notes

• The implementation shouldn't impact existing documentation;
• Batch limit support should be done along Handle BATCH request limit #13, not here.

[n1k0]

This is now ready for review. r=? @leplatrem @Natim @ametaireau

[leplatrem]

nit: I would have put the trailing slash here, so that assembling urls remains consistent (with / as join char)

[Natim]

Some version of the protocol don't have the settings parameter. What is the client behavior in case the settings is undefixed? Shall we consider that the server doesn't follow the protocol in that case or should we fallback to default values on client side?

[n1k0]

Some version of the protocol don't have the settings parameter.

Which versions? The client is designed to support a single version of the protocol, which is v1. Do you mean it should also support previous versions of that version?

What is the client behavior in case the settings is undefi_n_ed?

You get an error. TBH I don't really want to start supporting versioning the version.

[Natim]

In that case it means we should document the list of provided settings in kinto documentation.

[leplatrem]

r+

+1 to document settings explicitly in Kinto endpoints docs

[n1k0]

+1 to document settings explicitly in Kinto endpoints docs

You mean in Kinto server, right? Server settings are transparent for client users.

[Natim]

You mean in Kinto server, right?

Yes, see Kinto/kinto#133