@Override public String toString() {
    return input.toString().replace("Input", "InsertSpan");
  }
TLDR: we are guarding against setting null, as doing so implies tombstones. We are dodging setX
to keep code simpler than other alternatives described below.

<p>If there's consistently 8 tombstones (nulls) per row, then we'll only need 125 spans in a
trace (rows in a partition) to trigger the `tombstone_warn_threshold warnings being logged in
the C* nodes. And if we go to 12500 spans in a trace then that whole trace partition would
become unreadable. Cassandra warns at 1000 tombstones in any query, and fails on 100000
tombstones.

<p>There's also a small question about disk usage efficiency. Each tombstone is a cell name
and basically empty cell value entry stored on disk. Given that the cells are, apart from tags
and annotations, generally very small then this could be proportionally an unnecessary waste of
disk.

<p>To avoid this relying upon a number of variant prepared statements for inserting a span is
the normal practice.

<p>Another popular practice is to insert those potentially null columns as separate statements
(and optionally put them together into UNLOGGED batches). This works as multiple writes to the
same partition has little overhead, and here we're not worried about lack of isolation between
writes, as it is asynchronous anyway. An example of this approach is in the cassandra-reaper
project here: https://github.com/thelastpickle/cassandra-reaper/blob/master/src/server/src/main/java/io/cassandrareaper/storage/CassandraStorage.java#L622-L642
zipkin-storage/cassandra/src/main/java/zipkin2/storage/cassandra/InsertSpan.java