Document RPC failure modes of the API calls

Registered by Bogdan Dobrelya

Address all of the RPC timeout based failure modes of the API documentation in order to
keep messaging library developers and apps developers "at the same
page".

        Typical RPC (with the message broker involved) call is:
        1) A caller (RPC client) subscribes to an exchange using
        unique key to receive a reply from RPC server
        2) The caller send RPC request to a exchange
        3) A subscriber (RPC server) consumes the request, make a
        work and send a reply back using the unique key
        4) The caller receives the reply and unsubscribe from the
        exchange.

The must have failure scenarios to be addressed in the API docs:
        Use case #1 - Everything is working fine (no timeouts raised)

        Use case #2 - RPC client sent a request to an exchange and

        Use case #3 - RPC server consumes a request (ack it) and died
        without sending a reply back.

        Use case #4 - RPC client sent a request and connected broker
        node dies. RPC client didn't receive a confirmation envelop
        from the broker.
        There are three subcases - a request may be still delivered,
        a request is completely lost and a request is being duplicated.

        Use case #5 - RPC server consumes a request and sends ack
        back to broker node but the node dies.
        There are two subcases: a request will be acknowledge/removed
        from the queue and a request will be duplicated.

        Use case #6 - RPC server sends a reply back but a broker node
        dies
        There are two subcases: a reply is lost and a reply is
        duplicated.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Bogdan Dobrelya
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Not started
Milestone target:
milestone icon 1.16.0

Related branches

Sprints

(?)

Work Items

Work items:
Address expected behavior for the given failure modes in the spec: TODO
Figure out missing / unmatched expectations against the actual code's behavior: TODO
Submit patches to address missing / unmatched expectations: TODO

This blueprint contains Public information 
Everyone can see this information.