some problem with default finite fields

[ThomasBreuer]

Describe the bug

Using a default finite field F (of type FqField) in the construction of GL(n, F) causes errors in centralizer computations.

To Reproduce

julia> using Oscar
[...]

julia> G = GL(3, Nemo._GF(3, 1))
GL(3,3)

julia> x = G[2];

julia> centralizer(G,x)
ERROR: MethodError: no method matching lift(::FqFieldElem)
[...]

Expected behavior

The centralizer should be returned.

System:

julia> Oscar.versioninfo(full=true)
OSCAR version 0.13.0-DEV
  combining:
    AbstractAlgebra.jl   v0.31.0
    GAP.jl               v0.9.6 - #master, 5f85453 -- 2023-07-26 13:54:46 +0200
    Hecke.jl             v0.19.6 - #master, 00dab43d8 -- 2023-07-14 10:33:32 +0200
    Nemo.jl              v0.35.1 - #master, 011e590c -- 2023-07-21 12:19:18 +0200
    Polymake.jl          v0.11.1
    Singular.jl          v0.18.8
  building on:
    Antic_jll               v0.201.500+0
    Arb_jll                 v200.2300.0+0
    Calcium_jll             v0.401.100+0
    FLINT_jll               v200.900.7+0
    GAP_jll                 v400.1200.200+5
    Singular_jll            v403.203.202+0
    libpolymake_julia_jll   v0.10.2+0
    libsingular_julia_jll   v0.35.0+0
    polymake_jll            v400.1000.1+0
See `]st -m` for a full list of dependencies.

Julia Version 1.8.5
Commit 17cfb8e65ea (2023-01-08 06:45 UTC)
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 8 × AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-13.0.1 (ORCJIT, znver1)
  Threads: 1 on 8 virtual cores
Official https://julialang.org/ release

Additional context

The problematic function is _centralizer(f::PolyRingElem{T}) where T <: FinFieldElem (in Oscar.jl/src/Groups/matrices/stuff_field_gen.jl).
It wants to call Hecke.field_extension(f), but this is available only if the type of f matches Union{FqPolyRepPolyRingElem, fqPolyRepPolyRingElem}. In all other cases, the auxiliary function Oscar._change_type(f::PolyRingElem{T}) is called which replaces f by an equivalent polynomial of type fqPolyRepPolyRingElem; for that, it tries to map the coefficients of f to an appropriate field, using lift, and this does not work in our situation.

I am not sure how a good solution looks like.
Should Hecke.field_extension(f) work for other types of polynomials? If yes then replacing f is unnecessary.
Or should some standard way for replacing f be used? If yes then lift is not a general solution, since it makes sense only for prime fields.

(Perhaps @thofma or @fieker can give advices.)

[thofma]

I will have a look