feat: Bot instances advanced filter

[nicholasmarais1158]

Summary

This change adds an advanced search to the bot instances list.

The following fields can be accessed from the predicate language;

• metadata.name (alias name)
• spec.bot_name
• spec.instance_id
• status.latest_heartbeat.architecture
• status.latest_heartbeat.os
• status.latest_heartbeat.hostname
• status.latest_heartbeat.one_shot
• status.latest_heartbeat.version
• status.latest_authentication.join_method

In addition to the standard functions, the following are bot instance specific;

• more_than (e.g. more_than(status.latest_heartbeat.version, "18.7.25"))
• less_than (e.g. less_than(status.latest_heartbeat.version, "18.7.25"))
• between (e.g. between(status.latest_heartbeat.version, "18.7.25", "18.7.72"))
• equals (e.g. equals(status.latest_heartbeat.version) == "18.7.25"))

Updates: #57994
Depends on: #59263

TODO:

• Check if any docs need to be added to or amended (such as this) - no changes required for this change but will add details to the tclt reference when the --query flag is added.

Changes

• Add expression parser with functions specific to bot instance resources
• Support query parameter in webapi and RPC.
• Add advanced filter to web UI
• Fix an issue preventing submitting the SearchPanel form when the advanced toggle is present (affects tests only)

Demo

Screen.Recording.2025-09-19.at.17.40.42.mov

Reviewer notes

Creating bot instances (as well as heartbeat records) requires running tbot to enrol an instance. To make testing this feature easier, I've used a SQL script to insert instance resources into the backend directly. Here's the script;
bot_instances.sql

$ sqlite3 <your cluster's data dir>/backend/sqlite.db
sqlite> .read bot_instances.sql

Be sure to restart your cluster afterwards - the cache will not be notified of the changes.

[nicholasmarais1158]

@strideynet @espadolini I've removed the general-use to_string function as it was too difficult to make it nil-safe. This was intended to allow version comparison using the basic == operator, like so; to_string(status.latest_heartbeat.version) == "1.0.0"

Instead I've added an equals function that only operates on *semver.Version and is not general-use (i.e. not contributed to the default set of functions/methods). It's used like this; equals(status.latest_heartbeat.version, "18.2") and allows loose matching on the given prefix.

[espadolini]

loose matching on the given prefix

So a hypothetical Teleport v2026 is going to match "20" (or better yet, Teleport 19.12 will match "19.1"). 😓

The name "equals" is also a bit awkward, it's not really an equality if it's fuzzy IMO.

Will we be able to add functions with the same name and different type signatures in the future if we decide we need them? Or should the function name indicate that they operate on versions?

[backport-bot-workflows]

@nicholasmarais1158 See the table below for backport results.

Branch	Result
branch/v17	Failed
branch/v18	Failed