only recalculate scan profiles in Octopoes when OOI's have been changed

[underdarknl]

About this feature

Currently, we have a static interval for doing a recalculation of the scan profiles in Octopoes. We should only do this loop if we have changes in the Octopoes database.

Detailed description

Optimize this by setting a tainted flag on the orga. Unset the taint flag after recalc is done. Only run recalc if taint flag is high,

Feature benefit/User story

As a user I want to have thousands of organizations which are mostly static, and as such do not incur any changing or new scan profiles.

Specifications

Please add some specifications for the implementation. What needs to be implemented to match the design?

The implementation should include…

• Specification 1
• Specification 2

Additional information

Any additional information, considerations, or context that might be helpful for understanding or evaluating the feature request.

Design

This part should only be filled in by the OpenKAT design team.

Screenshots

Include screenshots of the proposed design changes here.

Figma link

Link to the Figma design for further visualization (if applicable)

Implementation

This part should only be filled in by the developers.

Possible solution

Outline your proposed solution for implementing the feature. You can include any specific ideas, designs, or functionalities here.

Alternatives considered

Describe any alternative approaches or solutions you've considered, and why you believe the proposed solution is superior.

[originalsouth]

Upon researching this issue a bit, and having once again a very constructive talk with @noamblitz, thanks you!

Naively one would track OOI changes with the event manager and forward these to the scan profile (re-)calculation.

According to @noamblitz this was the original design (I lack the historical context and the repository is squashed at this point), but this gave problems of instability as any change will recursively evoke changes causing recalculates to trigger recalculates etc.

There seem to be two ways around this:

1. Easy collect a set of changes within the poll time and hope this converges.
2. Hard, but more efficient and flexible, calculate scan profiles similarly to nibbles. As scan profile calculations are essentially "inference"-rules a nibble architecture is capable of handling such problems. As a plus, "special" rules can be configured for certain OOI's and the like.

@underdarknl what do you think about the approaches?

[underdarknl]

It has been a long standing dream to implement scan-level propagation as bits, (and as such, now as nibbles). This would also make them more Turing complete, as you could do propagation based on much more complex rules.

This does not negate the fact that there might be deductions which are incompatible with each other and as such never converge. To guard against this, we should design safeguards / detection mechanisms that signal the user when these loops occur, which is probably a hard problem by itself.