Proof-of-concept: Introduce HTMX-based replacement for QuickSelect component in Maintenance tool

[lunkwill42]

This is related to both #2639 and #2251 .

It's a very crude start to a PoC that can potentially replace the b0rked QuickSelect component used in the Maintenance tool. The QuickSelect component is also used by the IP Device History tool, and could be replaced also there once complete.

Quick explanation, for now: The QuickSelect component is pre-populated with all netboxes, locations, rooms, services, etc. from NAV, and is consequently output into the resulting HTML of the maintenance task edit form. From that HTML, QuickSelect's JavaScript counterpart allows the user to filter form values from this potentially giant list of stuff. This is exactly why the page load times can grow very long in big NAV installs, as mentioned in #2251. It will grow even bigger if we add an option to put interfaces on maintenance, which is a feature that has been suggested to us.

This PR intends to demonstrate how to use HTMX to dynamically look up maintenance components by having the backend do the searching and return fully formed HTML with the results. The potential downside to this approach is that there will be no initial scrollable list of all components: The user must enter at least a single letter search query to see any selectable components. This might still be preferable to loading "everything" from the database into an HTML fragment (this is equivalent to the API strategy that refuses to return all the millions of ARP entries when no arguments are given to the endpoint)

[github-actions[bot]]

Test results

       8 files         8 suites   4m 18s :stopwatch: 3 321 tests 3 321 :heavy_check_mark: 0 :zzz: 0 :x: 4 940 runs  4 940 :heavy_check_mark: 0 :zzz: 0 :x:

Results for commit f123d855.

:recycle: This comment has been updated with latest results.

[lunkwill42]

There ought to be a naming convention for html templates that do not contain {% extends ..%}, that is: html fragments changing parts of a page, not an entire page.

Since NAV never started out as a Django project, there has never been an explicit agreed-upon convention for this in NAV. I suspect a lot of this is pretty unused in NAV to distinguish fragments today, except for one subsystem: ipdevinfo uses the *-frag.html convention, so perhaps we should continue using that going forward (but a decision should be made and documented in the "hacking" section of the docs, I guess)

[podliashanyk]

Some possible naming conventions:

• Prefix with _ (single underline)
• End with -frag.html, not .html
• End with -partial.html, not.html

I don't have any particularly strong opinion on this one. But here are my thoughts:

• I slightly prefer the prefix with _ (single underline) option since it is easy to quickly visually grasp what template is what when looking at the file structure, f.e.:
• Between -frag.html and -partial.html options I slightly prefer the former because of brevity

The differences are minuscule IMO and are more a case of personal preferences. Unless we discover some more "technical" reasons to choose one over the other..

[podliashanyk]

Discovered another naming variant used in NAV:

• partials (no special prefix or ending in name) placed in /fragments directory, see python/nav/web/templates/seeddb/fragments