Bug 565684

Description Elena Parovyshnaia 2020-07-30 02:08:36 EDT

Each of the access cycle phase can fail for a wide variety of reasons. Some of the failures can be as critical as to stop the flow, others are bearable, but worth attention. 

We must keep all the dialgnostic events through all of the access cucle calculations and, if demanded, be able to expose this information to the end user.

Currently almost every part of new access cycle uses it's own way to handle evnvironmental denials and data ddiscrepancies.  
 - requirement resolution, if failed, generated sinthetic unsatisfiable requirement and thus prevents the cycle from success
 - condition mining uses two strategies: 
      - general exception is thrown if no source cannot be mined at all (runtime or condifurational crucial errors)   
      - but if the source is achieved, it's mining failure must not breake the flow, so each exception on the actual mining (data driven errors) are handle by a specially configured consumer
 - condition evaluation, even can failure at many aspects severely (condition expression parsing, token assessment, final evaluation), all these failures must not stop the flow, that are gathered into a `diagnostic` object and the phase itself does not even throw an exception
 - permisions examination service, as does not depend on environments, does not throw any exception, but has a gialdnostic potential: it enlists, which requirements are not satisfied, but does supply information about incative permissions. 
  

Thus, there are 4 different mechanisms. They should be 
 - unified (evolve condition evaluation's way: gathering diagnostic)
 - support accumulation
 - result must be accessible in a restriction execution service, as this phase achieves the end user