Add a timeout as a query parameter

[edeutsch]

Requested by Shervin on Architecture: https://docs.google.com/document/d/16agzJB0OlR8z-zU3nTivYYIo09sdayN-tu8lbrZyTXY/edit?pli=1

Previous discussion: Shervin - Can we add the timeout as a query parameter into TRAPI? Chris - ARAGORN can accept a timeout parameter. It assumes 5 minutes but will work longer if a longer parameter is sent. Jackson - BTE does not support a timeout. It’s adjustable via environment parameters but not on the fly via a query. Kaiwen - we do have a timeout parameter - unsure if it can be a TRAPI request parameter. Per Will it could be re-added. Max - we are not expecting ARAs to accept a parameter. Can we make it a parameter so it’s not hardcoded? Can all the components be flexible?

[edeutsch]

Possible addition to Query:

        max_allowed_time:
          type: integer
          default: 300
          description: >-
            Maximum number of seconds that the client is willing
            to wait for a response. If the service knows at query
            time that it cannot service the request within the
            specified time, it MAY respond with a 429 HTTP code.
            If the service discovers that it has taken more than the
            specified number of seconds while processing, it SHOULD
            return a 429 HTTP code.

Possible addition to AsyncQuery:

        max_allowed_time:
          type: integer
          default: 300
          description: >-
            Maximum number of seconds that the client is willing
            to wait for a response. If the service knows at query
            time that it cannot service the request within the
            specified time, it MAY respond with a 429 HTTP code.
            If the service discovers that it has taken more than the
            specified number of seconds while processing, it SHOULD
           post a Response to the callback with a status of "Timeout"
           and an entry in logs to indicate what happened.

[edeutsch]

Note that web servers such as Apache, nginx have a settable parameter that is set to some timeout. We could never make a timeout longer than what the web servers are set for.

Based on the call Oct 3, there is no urgency on this and can wait official TRAPI 1.6 development.

consider putting all query control parameters like log_level, bypass_cache, max_allowed_time into a top-level container within Query and AsyncQuery