Refactor span storage

[savhappy]

[ WIP] Needs test adjustment and specs
Considerations:
Should we store root spans and child spans in separate tables?
Storing key/values like this -> parent: {{:root_span, span_id}, span} child: {parent_span_id, span}
Should we implement some sort of sweep in case spans don't get removed on_end
Should we order the child spans in the table? Or have an inserted_at value?

[savhappy]

@whatyouhide refactored with the genserver added. Left a comment wondering if we should sweep based on ttl or something else to avoid build up.

@solnic I have two failing test that I'm confused about..

  1) test sends captured spans as transactions with child spans (Sentry.Opentelemetry.SpanProcessorTest)
     test/sentry/opentelemetry/span_processor_test.exs:59
     ** (FunctionClauseError) no function clause matching in Calendar.ISO.parse_utc_datetime/2

     The following arguments were given to Calendar.ISO.parse_utc_datetime/2:

         # 1
         nil

         # 2
         :extended

     Attempted function clauses (showing 1 out of 1):

         def parse_utc_datetime(string, format) when is_binary(string) and (format === :basic or format === :extended)

     code: assert_valid_iso8601(transaction.timestamp)
     stacktrace:
       (elixir 1.17.2) lib/calendar/iso.ex:591: Calendar.ISO.parse_utc_datetime/2
       (elixir 1.17.2) lib/calendar/datetime.ex:1233: DateTime.from_iso8601/3
       test/sentry/opentelemetry/span_processor_test.exs:112: Sentry.Opentelemetry.SpanProcessorTest.assert_valid_iso8601/1
       test/sentry/opentelemetry/span_processor_test.exs:67: (test)
     

Thoughts?

[whatyouhide]

If the table is tied to this GenServer, where would we ever have the table running without it that we need this check?

[whatyouhide]

Scope this to Sentry, as the ETS namespace is global. My suggestion is

Suggested change

	@table :span_storage
	@table __MODULE__