can't we just revert to the old behavior by using the host status attribute as a global status? and change the UI that it fetch the status info only if needed (or async)?

As discussed today in person, the problem is not the relevant? method and it can't be stored in DB since some host statuses change their statuses during runtime based on current time or application configuration. E.g. code from build status

    def to_status(options = {})
      if waiting_for_build?
        if token_expired?
          TOKEN_EXPIRED
        else
          PENDING
        end
      else
        BUILT
      end
    end

    def relevant?(options = {})
      SETTINGS[:unattended] && host.managed?
    end

We should first avoid this pattern so that TOKEN_EXPIRED and PENDING are flipped correctly at the right time. For that we need to have some optional timestamp that we set during the status updated. This timestamp would define when the refresh on this status should be considered. Then we need async worker that finds all host statuses with such timestamp in past and run the refresh. The same applies to configuration status that gets out of sync after some period in which we don't receive puppet report. We should just bump the timestamp by the interval from SETTINGS on every report processing.

can't we just revert to the old behavior by using the host status attribute as a global status? and change the UI that it fetch the status info only if needed (or async)?

This is the old behavior, the build and configuration status were based on time. The only change that happened is that we moved statuses from host table to host_statuses table so plugin can introduce their own. I don't think that's the main problem. The main problem is that we can't rely on status stored in DB with current (and old) status implementation and we need to verify whether the status e.g. represented by code 1 actually means "Pending" or "Token expired".