If you are developing a Business Rule Engine (BRE), which implies unattended, fully-automated operation, my suggestion is to avoid being strongly-coupled to the use of cases, flows, assignments, and SLAs at least in terms of a universal REST connector management approach.

Option 1: The ConnectionProblem flow allows someone to manually reissue a connect request at the location in a flow where the connector failed.  Since this is flow-related and you are developing a BRE, I would not recommend using it as a universal connector management solution.

Option 2:  Use of assignment SLAs to automatically reissue connection requests in the event of failure also involves strong coupling to flows. Plus, the primary purpose of SLAs is to provide data regarding the proficiency of human requestors to complete a task. I would not recommend using this approach as well.

Option 3:  IMHO this is the best approach for a BRE, i.e., recording connect attempts in a data table, updating a row in that table every time a connect request fails, etc..  You mentioned creating an activity to monitor the table which sounds like you would implement an Advanced Agent.  My suggestion is to instead use a Standard Agent as described below.

A Standard Agent can be queued against any step page class you choose; Standard Agents are not limited to being launched within flows.  For example, it is possible to queue a Standard Agent from an Advanced Agent where the Queue-For-Agent step page is some Data- class, for example, Data-Party.

The two requirements when using a Standard Agent are: (1) persisting the step page and (2) persisting the queued System-Queue-DefaultEnty record created by Q-F-A.  This means a commit has to be issued after Q-F-A is called. The System-Queue-DefaultEnty EstablishContext activity essentially invokes Obj-Open-By-Handle to restore the step page. Your persisted step page should use a Data- class that ensures a unique pzInsKey.  Consider calling a function that returns a GUID such as @pxGetNewGUID() and assigning that value to a singular "Key" property.  Also note the Locking tab on the Data class rule.

When the Standard Agent activity encounters a connect failure it can increment a failure count on the primary page, i.e., the original step page, issue Obj-Save, then re-queue itself by invoking another Q-F-A call. If the number of failures has become excessive, an email can be sent to an administrator.

The only remaining problem to solve in terms of a universal solution is capturing all of the information regarding what REST connector to invoke, how to populate the request, and how to process the response.  Note that a REST connector-sourced Data Page encapsulates all of this except the "capture" aspect. 

Request and response capture would need to take place within your originally persisted step page.  It would be very complex for the step page class to know how to persist each unique response within a different embedded page within different cases types.  Rather than implementing a solution where the step page class “visits” the case, or whatever "RequestIssuer" had issued the REST connect request, the universal solution would require that the REST connector issuer “visit” the successfully completed, persisted step page.

Note that the above is similar to how an asynchronous service behaves except here the originating RequestIssuer polls a persisted step page populated by a REST connector-invoking standard agent.  A second Standard Agent could be spawned against the RequestIssuer step page to perform the polling process.