Make Velox compatible with fmt >= 9

[assignUser]

Description

AFAIK the main issue is fmtlib/fmt#3131

[majetideepak]

Another reason to upgrade is fmtlib/fmt#1895 (comment)
fixed here fmtlib/fmt#2426
I believe the error described here prestodb/presto#21492 (comment) can be fixed by upgrading.

In file included from /Users/mbasmanova/java/presto/presto-native-execution/velox/velox/external/md5/md5.cpp:28:
In file included from /usr/local/include/folly/Conv.h:124:
In file included from /usr/local/include/folly/Demangle.h:19:
In file included from /usr/local/include/folly/FBString.h:34:
/usr/local/include/fmt/format.h:1775:12: error: expected unqualified-id
  if (std::signbit(value)) {  // value < 0 is false for NaN so use signbit.
           ^
/Library/Developer/CommandLineTools/SDKs/MacOSX14.0.sdk/usr/include/math.h:171:5: note: expanded from macro 'signbit'
    ( sizeof(x) == sizeof(float)  ? __inline_signbitf((float)(x))        \

[assignUser]

While working on the folly bump I incidentally discovered the ostream.h related issues we have to fix. 1. ostream.h is included transitivly via Exceptions.h basically everywhere so just grepping for it only gives 1 hit but that is deceptive.

The issue we have to fix are things like this (or with use of <<):

 struct {
    uint8_t startBitOffset;
    int32_t numBits;
    uint8_t bitOffset;
    int32_t maxSpillLevel;
    int32_t expectedExceeds;

    std::string debugString() const {
      return fmt::format(
          "startBitOffset:{}, numBits:{}, bitOffset:{}, maxSpillLevel:{}, expectedExceeds:{}",
          startBitOffset,
          numBits,
          bitOffset,
          maxSpillLevel,
          expectedExceeds);
    }
  } testSettings[] = {
      {0, 2, 2, 0, true},
      {0, 2, 2, 1, false},
      {0, 2, 4, 0, true},
      {0, 2, 0, -1, false},

The formatting in the unnamed struct causes the error:

Cannot format an argument. To make type T formattable provide a formatter specialization: https://fmt.dev/latest/api.html#udt

What would be your preferred method to fix this? Should we specialize a 'reporter struct' or something like that, that can be used for the unnamed structs like this?

[majetideepak]

| Should we specialize a 'reporter struct' or something like that, that can be used for the unnamed structs like this?

@assignUser Can you elaborate on this proposal? From the link you shared I see that for named structs we need to provide a formatter specialization inherited from ostream_formatter.
How will a reporter struct look like?

[assignUser]

Likely I misunderstood the documentation because my cpp is pretty rudimentary for now.

I'll let you propose a solution :) but feel free to ping me if I can help implement it!