Add initial spans for opentelemetry

[KyleAMathews]

We have the initial setup of opentelemetry done but let's now add the following basic spans & attributes (not exhaustive, whoever does this feel free to add more that seem right):

• shape http request
  • attributes:
    • url
    • query parameters
    • and other http info e.g. requester, status code that we return, body size, etc. etc.
• sql query when creating snapshot
  • attributes:
    • shape_id
    • the full query & parts of it broken up e.g. the table, select clause, where clause, etc.

[KyleAMathews]

A few notes from testing just now:

We'll want is_cached, is_live, and offset attributes added to shape handling spans.

For replication log spans, we need spans created for the code that updates the shape & sends it to any subscribers. That way we can see the tree of a replication log coming to Electric & then all subsequent work to update shapes & subscribers.

[KyleAMathews]

I also think we should just have one shape for all shape requests — a simpler name would be nice too — e.g. ShapeGet. We could then have ShapeDelete (or shape_get and shape_delete).

[KyleAMathews]

We need an attribute to distinguish between requests that go into long polling or just immediately respond. is_live isn't sufficient as if a user is behind the tip of the log they get an immediate response. Perhaps a is_long_polling attribute.

[KyleAMathews]

We need attributes about the shape — table, shape_definition which includes the table & where clause and any other shape definition.

Also the size of the response body (aka the size of the shape)

[KyleAMathews]

Common queries will include:

• number of unique shapes
• number of unique shapes grouped by table
• time to fetch shape uncached vs. cached
• relationship of shape size to response time (cached and uncached)

[thruflo]

is_immediate_response?

[KyleAMathews]

is_immediate_response?

yeah that works too — true for normal responses and false for long polling