Add a 5 seconds timeout to all HTTP requests

[ctrlaltdel]

By default python requests library might hang indefinitely in case of network
issues. See https://requests.readthedocs.io/en/master/user/advanced/#timeouts

[badnetmask]

I think if you're creating a way to set a request timeout, it would also be good if this was exposed to be defined by the module user, as a variable.

[Deconstrained]

Hi @badnetmask,

I'm really sorry for the increased latency in updates on this project and I plan on devoting a few hours this week and weekend to a bit of upkeep.

I agree with your idea, but what you have so far is perfectly fine for now; thank you @ctrlaltdel for contributing!

My only criticism is that the improvement could be made much fewer lines by modifying the request method, i.e. changing the keyword args sent to requests.Session.request (the req_kw dictionary):

pdpyras/pdpyras.py

Lines 495 to 500 in b359a88

	req_kw = deepcopy(kwargs)
	my_headers = self.prepare_headers(method)
	# Merge, but do not replace, any headers specified in keyword arguments:
	if 'headers' in kwargs:
	my_headers.update(kwargs['headers'])
	req_kw.update({'headers': my_headers, 'stream': False})

[ctrlaltdel]

Thanks for the feedbacks, I'll update the code while taking into account both comments.

[ctrlaltdel]

I think if you're creating a way to set a request timeout, it would also be good if this was exposed to be defined by the module user, as a variable.

What would the API for setting this timeout looks like in your opinion? And what kind of use-cases do you see?

I'm not sure it is worth adding a new variable to the constructor of both APISession and EventsAPISession classes to expose this timeout.

A user can still set pdpyras.TIMEOUT directly if really necessary.

The main use-case for this change is that we have a custom script using this library which got stuck forever when the network it was running on was attacked by a DDoS.

[Deconstrained]

A pattern I've loosely followed (and I won't say it's the best, but it works) is to let sessions be mutable objects and allow modifying their settings (i.e. retry / cooldown) by setting their attributes. That might help here.

While it's not very common for endpoints to take longer than 5 seconds to respond, there are a few (i.e. /oncalls) where this could potentially happen.

[Deconstrained]

Added this so that it'll get covered by retry logic:

#49

[Deconstrained]

Nice!

[Deconstrained]

Thanks again for the contribution!