Repair quotient rings

[HechtiDerLachs]

CC: @wdecker , @fingolfin @fieker

[thofma]

Was it decided at one of the Kaiserslautern meetings, that we'd rather have a hash functions which errors than a slow default one?

[HechtiDerLachs]

Yes. This was @fieker 's proposal.

[lgoettgens]

Was it decided at one of the Kaiserslautern meetings, that we'd rather have a hash functions which errors than a slow default one?

This is similar to oscar-system/GAP.jl#891.

[codecov]

Codecov Report

Merging #2788 (4e0bf93) into master (79874fd) will decrease coverage by 0.05%.
Report is 5 commits behind head on master.
The diff coverage is 73.04%.

@@            Coverage Diff             @@
##           master    #2788      +/-   ##
==========================================
- Coverage   73.63%   73.58%   -0.05%     
==========================================
  Files         455      455              
  Lines       64411    64443      +32     
==========================================
- Hits        47427    47422       -5     
- Misses      16984    17021      +37     

Files Changed	Coverage
experimental/JuLie/src/schur_polynomials.jl	ø
...ntal/QuadFormAndIsom/src/lattices_with_isometry.jl	ø
experimental/Schemes/CoveredProjectiveSchemes.jl	ø
experimental/Schemes/elliptic_surface.jl	ø
src/AlgebraicGeometry/Schemes/Glueing/Methods.jl	ø
...eometry/Schemes/ProjectiveSchemes/Objects/Types.jl	ø
src/Modules/FreeModules-graded.jl	0.00%
src/Modules/ModulesGraded.jl	0.00%
src/Rings/mpoly-affine-algebras.jl	0.00%
src/Rings/mpoly-graded.jl	0.00%
... and 14 more

[HechtiDerLachs]

Looks like the code coverage report is nothing that can be taken serious these days. All coverage changes occur in places that I did not touch; not even indirectly! I suppose this is due to the various failing tests?

Either way: I would like to point to #2789 if anyone feels like doing a proper review.

[simonbrandhorst]

This looks wrong to me. Please double check

[HechtiDerLachs]

Indeed. What was I thinking...? Corrected in #2789 .