Use named accessors for decoded indexing events

[jwils]

Why

The shared indexing pipeline reads decoded events through string keys. Its latency logger also requires json_schema_version, so a valid non-JSON event can fail after the datastore write.

What

Introduce Indexer::Event as a format-neutral value object with named envelope fields, and remove the JSON schema version requirement from shared latency logs.

How

• Event stores named envelope fields and can be constructed directly from native decoder values. Event.from_hash preserves the original hash for format-specific validation.
• Format-specific decoders produce Event objects. The processor, operation factory, and remaining indexing pipeline accept only events.
• Adapters validate untrusted envelope values once and return Event::Validated. Shared operations then use concrete String, Integer, and timestamp types instead of untyped values.
• Envelope failures retain their unvalidated values so adapters can return clear validation errors. Record failures retain a validated envelope so superseded-event handling can still build operations.
• JSON decoding returns events, and SQS adds transport metadata before passing those events to the processor. The JSON adapter retains the exact source hash for schema validation.

Risk

This changes the decoder, processor, adapter, operation, and failure-event contracts. Extensions must pass Event objects to the processor and return validated events from adapters. ElasticGraphIndexingLatencies no longer includes json_schema_version.

Testing

No manual testing. A local full gem run did not start because the test datastore was unavailable. The full datastore suites run in CI.

Bigger picture

Non-hash ingestion decoders can construct Event directly and keep native records through adapter validation. The protobuf ingestion work in #1388 can use this path instead of manufacturing a JSON-shaped event hash.

[myronmarston]

There's an awful lot of untyped here, which means steep can't check type-system bugs with how we use these values. For example, we should consider which ones we want to make nilable or not, to force the caller to deal with potential nils where they may show up.

[jwils]

One of the issues here is that we don't have strong types until validation. Made some progress Let me know what you think of this approach.

[myronmarston]

You're using #[] for all these methods which gives less friendly errors than .fetch:

irb(main):001> hash = {}
=> {}
irb(main):002> op = hash["op"]
=> nil
irb(main):003> op.upcase
(irb):3:in '<main>': undefined method 'upcase' for nil (NoMethodError)
        from /Users/myron.marston/.asdf/installs/ruby/4.0.0/lib/ruby/gems/4.0.0/gems/irb-1.18.0/exe/irb:9:in '<top (required)>'
        from /Users/myron.marston/.asdf/installs/ruby/4.0.0/lib/ruby/site_ruby/4.0.0/rubygems.rb:305:in 'Kernel#load'
        from /Users/myron.marston/.asdf/installs/ruby/4.0.0/lib/ruby/site_ruby/4.0.0/rubygems.rb:305:in 'Gem.activate_and_load_bin_path'
        from /Users/myron.marston/.asdf/installs/ruby/4.0.0/bin/irb:25:in '<main>'
irb(main):004> op = hash.fetch("op")
(irb):4:in 'Hash#fetch': key not found: "op" (KeyError)
        from (irb):4:in '<main>'
        from /Users/myron.marston/.asdf/installs/ruby/4.0.0/lib/ruby/gems/4.0.0/gems/irb-1.18.0/exe/irb:9:in '<top (required)>'
        from /Users/myron.marston/.asdf/installs/ruby/4.0.0/lib/ruby/site_ruby/4.0.0/rubygems.rb:305:in 'Kernel#load'
        from /Users/myron.marston/.asdf/installs/ruby/4.0.0/lib/ruby/site_ruby/4.0.0/rubygems.rb:305:in 'Gem.activate_and_load_bin_path'
        from /Users/myron.marston/.asdf/installs/ruby/4.0.0/bin/irb:25:in '<main>'

IMO it's much nicer to be notified of the missing key rather than getting a NoMethod on nil error later.

So, it'd be good to use .fetch in the methods where we expect the key to always be there. (Of course, this is moot if you go with my suggested alternate EVent design from above).

[myronmarston]

I'd prefer to keep the stricter types--untyped essentially disables type checking on the returned value.

For the record below we could consider using generics for it. (That could also apply to Event as it also has record.

[myronmarston]

Oh this is interesting--I was thinking we wouldn't want to return nils for expected fields, but I hadn't thought about how it might turn clear validation errors into exceptions instead.

I'm not sure what's best here. Ideally the validation is handled in just one spot and the rest of the system can assume non-nil values.

[jwils]

Let me know what you think of the approach now with the validated event type. It relates to a few of the comments on typing. Event::Validated is now strictly typed

[myronmarston]

It's a little weird to go back to a hash here. You might consider doing something like:

class JSONEvent = ::Data.define(:base_event, :json_schema_version_key) do
  extend Forwardable
  def_delegatators :base_event, :id, :version, # ...etc
end

IIRC, there are some other spots in this PR where you .to_h to deal with JSON_SCHEMA_VERSION_KEY--this approach would let you deal with it as an attribute like any other.