Look into ways to invalidate the entire build less often

[jakemac53]

There are some common cases that invalidate the entire build today. It would be good to look at them individually to see if there is anything we can do:

• add a package dependency
  • happens transitively too potentially (on pub upgrade)
  • can we just patch the asset graph at all?
    • update all nodes with their new phase #
    • do we need to actually invalidate existing nodes? conceptually they shouldn't have changed unless they depend on a node which used to be a synthetic node and is now a real node.
  • or, maybe make builder ordering be more of a DAG and only invalidate the portions of the build that depend on the new nodes. We already start with a DAG and we flatten it to a list for simplicity of running things and having cheap checks to know if an input is available or not.
• sdk updates
  • should we only invalidate builders that explicitly use files from the sdk?
  • generally sdk libraries shouldn't change in meaningful ways
• build script changes
  • usually would happen on pub upgrade
  • ideally we would just invalidate the affected builders but that is difficult

[evanweible-wf]

@jakemac53 our teams' local dev workflows would benefit quite a bit from improvements to the handling of dependency updates, with the ideal scenario being that only the changed nodes/packages are invalidated. We have a large dependency tree and a lot of our dependencies are automatically upgraded upon release, and in some of our more product-centric repos it is common to have many feature branches being developed in parallel that have differing pubspec.yamls. Because of this, it's already common for the entire asset graph to be invalidated any time a branch is updated with master or when a dev switches between in-progress branches. Given that the largest of these repos have 5+ minute clean builds right now (which we're investigating separately), it's a significant developer pain point.

[jakemac53]

Doing something better for package graph updates definitely seems like a high value change which should hopefully be a fairly tractable problem. I think it makes sense to start there.