API: Fix timestamp(9) with identity partitioning.

[rdblue]

This fixes the bug described in #11775 (comment), which was caused by incorrectly constructing a new predicate using a literal value instead of the literal itself.

Here's a test that reproduces the problem:

  @Test
  public void testStringToTimestampNanosLiteral() {
    Schema schema = new Schema(
        Types.NestedField.required(1, "id", Types.LongType.get()),
        Types.NestedField.optional(2, "ts", Types.TimestampNanoType.withoutZone()));

    PartitionSpec spec = PartitionSpec.builderFor(schema).identity("ts").build();

    Expression expr = Expressions.equal("ts", "2022-07-26T12:13:14.123456789");
    Expression projected = Projections.inclusive(spec).project(expr);

    Binder.bind(schema.asStruct(), projected);
  }

What's happening is the projection will first bind the original predicate because it needs a bound ID reference rather than a name reference. That ID is used to find the partition fields that can project the predicate. The binding process produces the expected TimestampNanoLiteral(1658837594123456789L). The bug is in the Identity transform's projection code, which needs to produce a new predicate that is unbound and uses a reference for the partition field's name (the partition name does not have to match). When it constructs the new unbound predicate, it passes the underlying value rather than the unchanged literal.

Updating that line to pass the literal instead of the value fixes the problem because it doesn't lose the context that the value was already a nanosecond timestamp value.

[rdblue]

@ebyhr, I think this fixes your timestamp nanos issue.

[amogh-jahagirdar]

Great find, and thanks for the minimal repro test. It makes sense that the unbound predicate that's produced needs to be based off of the literal to preserve the fact that it's a timestamp nano; with extracting the value, the previous logic would surface a predicate based on a long which would then be interpreted as micros and incorrectly undergo a conversion to nanos.

[ebyhr]

@rdblue Thank you for opening this PR! I internally verified that this change fixes our issue.

[ebyhr]

nit: The package org.apache.iceberg looks redundant as this class already imports Schema.