Fix /users perf with security: idempotent admin?, drop inverse attrs from auth load

[alexskr]

Summary

• Make User#admin? idempotent so it doesn't re-load :role per call.
  serialize_filter (added during the agroportal sync for lastLoginAt
  visibility) invokes Thread.current[:remote_user]&.admin? once per
  serialized user. With security enabled, this turned every authenticated
  /users?include=all into an N+1 association reload over the requesting
  user's role.
• Auth middleware: exclude inverse attributes from the User load.
  attributes(:all) was including :provisionalClasses, which fans out
  across the entire ProvisionalClass graph on every authenticated request.
• Add test_admin_with_shallow_role_load covering the auth-middleware
  load shape (admin and non-admin) and the idempotency contract.

Partially addresses #285. This PR fixes the
performance issue itself (the per-instance admin? fanout and the inverse-attr fanout
in the auth middleware).

[mdorf]

I'm not sure if the existing API already includes createdOntologies as part of this call:

LinkedData::Models::User.attributes(:inverse)

[alexskr]

Good catch — checked.

User.attributes(:inverse) returns just [:provisionalClasses]. :createdOntologies is declared with handler:, not inverse:, so it isn't in that list.

However, the auth load doesn't end up fetching :createdOntologies either, because Goo's where#include silently drops handler-backed attrs at the include stage (goo/lib/goo/base/where.rb:262-264):

if @klass.handler?(opt)
  next
end

So even though attrs_to_load still contains :createdOntologies after the subtraction, the symbol never makes it into the SPARQL pattern and load_created_ontologies is never invoked on the auth path.

[alexskr]

Following up on #286 (comment) — the inline thread answers why :createdOntologies is excluded from the auth load (handler attrs are silently dropped by Goo's where#include), but it raised a more general question I want to flag separately, out of scope for this PR but worth tracking:

Should :createdOntologies be a handler in the first place, or should it be an inverse: attribute?

The same shape — "ontologies where this user is in administeredBy" — could be expressed as:

attribute :createdOntologies, inverse: { on: :ontology, attribute: :administeredBy }

That's how :provisionalClasses is already declared on User. Pros vs the current handler:

1. Standard ORM semantics: where(...).include(:createdOntologies) would actually load it. As a handler today, where#include silently drops it (goo/lib/goo/base/where.rb:262-264), so ?include=createdOntologies on /users is a no-op — data only loads on .createdOntologies method access.
2. Caller controls attribute depth: the handler's two-step query hardcodes Ontology.goo_attrs_to_load([:all]), so any consumer pays the full ontology load. With inverse:, the caller passes whatever they need via the regular include syntax.
3. Avoids the bring-invokes-handler footgun: Goo's recent bring change (ncbo/goo#73) made bring(handler_attr) invoke the handler instead of raising. Any code that calls user.bring_remaining now triggers a heavy two-query load. An inverse attr would just be a normal SPARQL pattern.

The handler does do two things an inverse: wouldn't directly:

• Scopes the first query to Ontology.uri_type via raw SPARQL — possibly a workaround for named-graph constraints that inverse: doesn't apply.
• Eager-loads matched ontologies with [:all] attributes, returning fully-hydrated objects.

If those two properties were a real design requirement, the handler stays. If they were convenience (or just inherited from upstream agroportal code without a specific reason), the inverse form is simpler and avoids the issues above.

Does anyone know the original reasoning? If not, I can file a separate issue to track switching to inverse: and seeing what breaks.

[mdorf]

Looks good aside from the comment about createdOntologies. Ready to merge.