Contract the legacy engine and verify the replacement

[marcinpsk]

Parent

#73

What to build

Complete the interface-family replacement by moving every remaining caller to the new family package, removing the legacy private family implementation, and proving behavioral and performance equivalence. The engine must finish as a compatibility facade with one authoritative family path behind it.

Acceptance criteria

• Automatic installation, prediction, interactive preview and apply, bulk operations, virtual-chassis reapplication, conversion, and deferred reconciliation all use the new family package.
• The engine contains only compatibility orchestration and unrelated rule behavior; it does not retain family discovery, planning, mutation, conversion, or reconciliation logic.
• Legacy private family helpers, legacy family dictionaries and tuples, and alternate mutation paths are deleted.
• The family package does not import the engine facade, and shared dependencies point only toward lower-level rule-selection and naming seams.
• Existing public engine entry points remain compatible for downstream callers.
• No compatibility layer remains for private helpers.
• The project domain glossary, architectural decisions, and user-facing documentation describe the final interface-family behavior consistently.
• The complete supported NetBox and Python test matrix is green, including real PostgreSQL transaction, signal, prediction, preview, bulk, conversion, and virtual-chassis coverage.
• No test simulates an out-of-band rename with a queryset update on an interface name column. Each helper writes the row the way another actor would, through a model save with this plugin's own receivers muted, so the suite exercises the real write path and does not depend on an environment that permits raw bulk writes to interface rows.
• Query-count and query-scaling checks are no worse than the existing-implementation baseline.
• The exact manual performance scenarios from Record existing automatic naming performance #74 are rerun on the same hardware and controlled software environment.
• The after artifact contains PostgreSQL work, raw wall-time and process-CPU samples, median, p95, and environment revisions in the same normalized format as the before artifact.
• The comparison report shows no database-work or machine-time regression beyond the baseline's observed variance. Any detected regression is resolved before completion.
• The before artifact, after artifact, and readable comparison summary are retained as review evidence.
• No new plugin database schema or recurring machine-time CI gate is introduced.

Implementation note

engine.py is down from 1619 lines to 785 and holds no family discovery, planning or mutation.
Device-level renaming gained the revalidation and row locking it never had.

Three criteria are still open, all about the performance evidence rather than the code:

• The after run was taken while the host was at load 17 to 44 from unrelated projects, so its wall
  and CPU samples are not evidence. The scenarios need rerunning on an idle host.
• The database-work half is settled and needs no rerun. This plugin's own committed callback issues
  fewer or the same statements in every scenario, from unchanged where no rule matches to -36% on
  virtual-chassis reapplication of eight modules.
• Two complete_model_save scenarios issue more statements than the baseline. The comparison
  attributes every added statement to core_objecttype, extras_customfield and
  extras_cachedvalue, which is NetBox's own per-save bookkeeping for the object types and custom
  fields the test database holds, and that population grew between the two runs. The control is the
  no-rule scenario, where this plugin returns before doing anything and its callback issues the same
  7 statements in both runs while the surrounding save costs 17 more. Neither increase is work this
  refactor added.

Evidence is in performance/baselines/ and performance/comparisons/.

Blocked by

• Unify prospective prediction and interactive preview #79
• Apply family plans in bulk and after virtual-chassis changes #80
• Convert flat breakout families through family plans #81

[marcinpsk]

Carried over from PR #83 review: database-alias consistency in the legacy path

PR #83 made the engine read the remaining (unplanned) interfaces through the module's database
alias, so plan_installed_families and that query can no longer come from two databases
(0e62d3e). Review then surfaced a second, pre-existing gap in the path this issue retires.

The legacy leftover rename path is not alias-aware:

step	database used
_apply_rule_to_interface → transaction.atomic()	default
_rename_in_place → iface.save()	the module's alias, via Django's instance routing
_name_exists_on_device → Interface.objects	default
_create_channel → Interface(...).save()	default

So a module loaded from a non-default alias would have its base rename committed on that alias
while the collision pre-check, the new channel rows and the enclosing transaction all use the
default alias. Nothing rolls back together.

This is unreachable today, because NetBox does not run DCIM models on a second database, and it
was deliberately not patched in PR #83: threading an alias through _apply_rule_with_family and
its four branches (_apply_rule_to_interface, _apply_channelized_rule,
_apply_breakout_rule_to_family, _apply_simple_rule_to_family) plus _rename_in_place,
_rename_for_family, _create_channel, _first_taken_name, _build_channelized_family and
_name_exists_on_device is investment in code that #81 replaces and this issue deletes.

Suggested acceptance criterion for this issue: after the legacy mutation paths are removed, one
alias decision covers a complete operation, so every query, transaction and save in automatic
renaming uses the alias the module row came from. The family package already does this via
family.module_db_alias and the db_alias recorded on each plan.

Raised independently by two reviewers on PR #83: #83 (comment)

[marcinpsk]

Added one acceptance criterion, on the tests rather than the engine.

Eight tests move an interface name behind the code's back to simulate an out-of-band rename, so that planning sees one name and execution finds another:

• tests/test_structural_families.py (the _cascade helper, plus the three deferred-reconciliation tests that use it)
• tests/test_vc_drift.py (three ambiguity and legacy-matching tests)
• tests/test_installed_families.py (stale member detection)
• tests/test_bulk_families.py (stale base refusal)

Each one does Interface.objects.filter(pk=...).update(name=...). The intent is right, the mechanism is not. A queryset update writes the column with no model validation, no signal and no changelog entry, so it does not reproduce what a real out-of-band actor does to the row, and it makes the test depend on a database connection that accepts a raw bulk write to a name column. A model save with this plugin's own receivers muted gives the same isolation, writes the row through the path production uses, and removes that environmental assumption.

This lands here rather than in its own change because #82 already reworks the engine seams these tests exercise, and the deferred-reconciliation and virtual-chassis helpers move with them.