Review navigation methodology

[bemson]

Since the introduction of "destination flags" in queries, I've been pondering a change with how authors navigate programs. Instead of relying on a method to clear waypoints and create a new route, this flag could be used exclusively instead.

This ticket will list the pros, cons, and ramifications of making destination queries the way to clear waypoints, vs particular methods.

[bemson]

Background on Salt navigation

One of the less transparent aspects of Salt is navigation scheduling. The schedule operates like a stack, so no state can remove targets set by another, and the last target set is the first one followed. Any targets set after the first are "waypoints", and the last target is considered the "destination". Changing the destination state requires clearing all existing - the assumption is that they would not be part of the route otherwise.

Until the destination flag appeared, only three methods let you clear waypoints: .callbacks(), .get(), and .wait(). Clearing waypoints also cleared or reset navigation arguments, something that would persist until the destination was reached.

The destination flag came about to support program tags that took queries, but needed a way to identify when the query should be a waypoint or destination. Without the flag, these tags would have required more verbose structures (like an Array or Object), in order to inform how the query would be used. 0.5.4 allows any query to use destination flags, but it is only observed for certain tags.

[bemson]

The fallback for this entire ticket is to have methods ignore d-flags (by default, at least). Simplifying usage rules would make it easier to understand the framework syntax as a whole.