Fix a crash when ActiveJob context include a range with TimeWithZone

[solnic]

If a range consists for ActiveSupport::TimeWithZone,
it will be serialized as a string.

Previously it would raise an error

TypeError: can't iterate from ActiveSupport::TimeWithZone

Closes #2545

[codecov]

Codecov Report

Attention: Patch coverage is 66.66667% with 1 line in your changes missing coverage. Please review.

Project coverage is 64.01%. Comparing base (cc1dc53) to head (1b9344a).
Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
sentry-rails/lib/sentry/rails/active_job.rb	66.66%	1 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (cc1dc53) and HEAD (1b9344a). Click for more details.

HEAD has 22 uploads less than BASE

Flag	BASE (cc1dc53)	HEAD (1b9344a)
	129	107

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2548      +/-   ##
==========================================
- Coverage   69.25%   64.01%   -5.25%     
==========================================
  Files         126      123       -3     
  Lines        4759     4707      -52     
==========================================
- Hits         3296     3013     -283     
- Misses       1463     1694     +231     

Components	Coverage Δ
sentry-ruby	59.68% <ø> (-0.31%)	⬇️
sentry-rails	59.22% <66.66%> (-37.52%)	⬇️
sentry-sidekiq	97.16% <ø> (ø)
sentry-resque	92.85% <ø> (ø)
sentry-delayed_job	95.65% <ø> (ø)
sentry-opentelemetry	99.31% <ø> (ø)

Files with missing lines	Coverage Δ
sentry-rails/lib/sentry/rails/active_job.rb	86.66% <66.66%> (-13.34%)	⬇️

... and 30 files with indirect coverage changes

[st0012]

Do we need to serialize individual components in the range? If the range is (1..10000) then it'd probably be pretty slow AND it'd allocate a new array with 10k elements in it.
Maybe in this case we just leave the argument until we find another element type that requires special treatments?

[solnic]

@st0012 we don't but it's the original behavior - is it OK to change it in a patch/bugfix release?

[st0012]

Ah is it because it was entering the Enumerable branch? In that case, let's leave it as it is.

[solnic]

@st0012 yes exactly :)

[solnic]

This PR introduced a new challenge where we have specs that now have min Ruby version requirements due to syntax that's used (end-less and begin-less ranges in this case).

To solve this, I introduced a new rake task called spec:versioned that allows you to define spec/versioned/x.y/**/*_spec.rb specs and they will be run when ruby meets the min version requirements specified via directory name. See 5609d89

@sl0thentr0py @st0012 are you OK with such a solution? One remaining bit is to figure out what to do with Rubocop that has Lint/Syntax and target ruby version set to 2.6, so now it fails.

[sl0thentr0py]

let's just not use fancy syntax please then

[solnic]

let's just not use fancy syntax please then

oh, it's not that - we just need verify that such ranges work with activejob context param serialization 😅

[sl0thentr0py]

I assume a simple if RUBY_VERSION guard around the spec doesn't work? If so, fine with this.

[solnic]

I assume a simple if RUBY_VERSION guard around the spec doesn't work? If so, fine with this.

hah yeah that was my instinct but then I realized that ruby parses entire file first, it won't skip anything due to conditionals so we were ending up with syntax errors.

Alright, gonna merge this in, FWIW I think it's gonna be useful for other stuff too.