Introduce basic support for $origin substitution in EntityPathFilter

[jleibs]

What

• Initial implementation of: Add support for $origin in EntityPathExpressions #5288
• Builds on top of: Convert the SpaceViewArchetype to use QueryExpression as a batch #5516

This is a very dumb first stab at doing variable substitution.

• Rather than parse the string to extract potential $vars it uses the input environment and blindly tries to substitute all the vars it knows about (currently only origin).
• The biggest downside of this is we get no feedback when a variable fails to substitute.
• There's just enough future complexity handling edge-cases (e.g. mismatched {, variable-termination, nested substitutions, etc.) that it might be worth pulling in a proper utility library, though I don't know if there's an obvious rust ecosystem choice here.

Working through this uncovered some complexities regarding what we store in different parts of the blueprint. For example, if we do the full substitution immediately when construction the EntityPathFilter, then we can't use that Filter to re-create the query with the variable substitutions.

Additionally, we need to know about these substitutions all the way back when evaluating whether we want to keep RecommendedSpaceViews because we need the substitutions applied to do the overlap-checking.

I suspect the direction we might want to go in is to split EntityPathFilter into a non-substituted representation, from which we can create a version that executes the substitutions, but I'm not yet sure what the storage should look like. For example, do we just create full EntityPaths that contain EntityPathParts with "$origin" in them and then run the substitution on the EntityPath?

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using newly built examples: app.rerun.io
  • Using examples from latest main build: app.rerun.io
  • Using full set of examples from nightly build: app.rerun.io
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
• If applicable, add a new check to the release checklist!

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[emilk]

Excellent!

[emilk]

One failure to call out it that $foo will also match $foobar.

But yeah, solving this in general is a bit tricky, since parsing ${foo}/bar as an entity path currently results in a warning being printed about unescaped special characters. If we remove that warning though, we could parse, then substitute.

Or we can push the subst_env into EntityPath::parse_forgiving and handle it there.

I think this is good enough as a first step though, but let's add a TODO linking to an actual issue listing the shortcomings and potential solutions

[emilk]

Actually, a better solution occurred to me: if we limit substitutions to the start of each expression, we can make something simple that works well: matching either the entire expression ($origin) or stripping the start ($origin/).

Motivation: all EntityPath:s are absolute, so it only makes sense to substitute the start of an expression!

If we do that, I think we should change subst_env: &HashMap<String, String> to prefix_subst_env: &HashMap<String, EntityPath> for clarity

[jleibs]

I see the rationale, though it feels a bit unnecessarily restrictive to me for marginal value.

For origin it obviously sense, but I think variable substitution is enough of a generic escape hook to just let users do the thing they are used to. It's very low cost for us to in the near future add an optional env parameter to SpaceViews that users can pass in.

This then become a natural stepping stone to re-usable templates in blueprints where you just re-use the exact same space-view, but set up a different substitution env.