Avoid deprecated generated_jit

[JelleAalbers]

What is the problem / what does the code in this PR do
Avoid a NumbaDeprecationWarning and a future crash from using the deprecated function numba.generated_jit.

Can you briefly describe how it works?
numba.generated_jit is deprecated: https://numba.readthedocs.io/en/stable/reference/deprecation.html#deprecation-of-generated-jit. I think most people don't see the warning message for this yet because our environments use numba versions that are more than a year old.

We use generated_jit in strax.endtime to condition its behavior on the dtype of its input. This PR replaces generated_jit with numba.extending.overload. An additional benefit is that we don't need to condition on the environment variable NUMBA_DISABLE_JIT anymore, this was one of the main reasons generated_jit was deprecated.

[coveralls]

coverage: 91.261% (-0.3%) from 91.539%
when pulling cbec3a8 on JelleAalbers:fix_generated_jit
into 21cc96e on AxFoundation:master.

[dachengx]

Thanks @JelleAalbers . Just to check my understanding. Now outside numba decorated functions, like barely call strax.endtime will not trigger the usage of _overload_endtime. This is different from before but is exactly the functionality of numba.extending.overload. Am I correct? I test with some toy functions and it seems yes.

[JelleAalbers]

Hi Dacheng -- thanks for the quick look! Yes, I didn't consider it, but if you call endtime from a non-jitted function you will get the regular non-jitted function after this PR, whereas previously you always got a jitted function (unless you set NUMBA_DISABLE_JIT).

Here that should be fine, the regular endtime is actually faster that its jitted cousin when called on its own. The overhead of switching into numba is more than that of the little bit of python attribute access endtime does. We just jit endtime because we need to call it from jitted functions, not because it speeds things up.

But if we had some complicated performance-critical function (that just has different implementations for different input types), the generated_jit behavior would have been nicer. There is a numba discussion on this here: numba/numba#8897.

[dachengx]

I think we should be fine with the performance if we always put complex calculations into numba jit. Thanks again!