Always apply specialized proxy methods recursively over data frames

[DavisVaughan]

Follow up to #1537

That PR implemented:

vec_proxy_equal.vctrs_rcrd <- function(x, ...) {
  # Recursively proxy using a data frame
  vec_proxy_equal(new_data_frame(x))
}

but that means that if vec_proxy_order/compare() for a rcrd class fall through to this, then vec_proxy_equal() will be called on each field, which isn't right.

To fix that, we need vec_proxy_order/compare() methods specifically for vctrs_rcrd which call their corresponding function internally after creating a data frame.

This requires tweaking the vctrs-rational class, because it relied on the vec_proxy_compare.vctrs_rational() method being run when sort(x) was called, but this is no longer the case because the new vec_proxy_order.vctrs_rcrd() method intercepts it instead.

[lionel-]

It feels like we could make it simpler by recursively proxying data frame proxies from the generics? Then the rcrd methods only need to call new_data_frame(). Do you think that would work?

[DavisVaughan]

Would that mean we remove the special data frame methods (like the one below) and let data frames fall through to vec_proxy() (which would be a no-op)?

> vec_proxy_equal.data.frame
function(x, ...) {
  df_proxy(x, VCTRS_PROXY_KIND_equal)
}

And then internally we'd say something like

r_obj* vec_proxy_equal(r_obj* x) {
  r_obj* method = KEEP(vec_proxy_equal_method(x));
  r_obj* out = KEEP(vec_proxy_equal_invoke(x, method));
  if (is_data_frame(out)) {
    # Apply proxy recursively if the proxy is a data frame
    out = df_proxy(out, VCTRS_PROXY_KIND_equal)
  }
  FREE(2);
  return out;
}

Noting that I still don't think we'd do this automatic recursion for vec_proxy(), that is handled by your other PR

[lionel-]

yep something like that

[DavisVaughan]

Ok, this PR now removes all of the specialized methods for data frames and record vectors, and instead relies on the fact that:

• Data frames return themselves as the proxy
• Records fall through to vec_proxy.vctrs_rcrd() which returns a data frame
• If a data frame is returned as the proxy, we now apply the proxy function recursively over the columns

I think this is nice because someone could, in theory, return a complicated data frame containing a df-col from their custom vec_proxy_equal() method, which currently breaks our internal C code because it assumes df-cols have been flattened. This change ensures that even if a custom method returns a data frame like this, we post-process it to flatten and potentially unwrap it.

Revdepcheck "b4fb11fb-cbef-445a-af0b-1601e7f6bd58" - passes with no changes to worse from this PR

[lionel-]

Looks like a great improvement.