Use `pillar::type_sum()` not `dplyr::type_sum()`

[DavisVaughan]

We'd like to eventually remove dplyr::type_sum(), which just reexports pillar::type_sum(). To do this, we need to switch sparklyr over to using the pillar version.

We import the dplyr version here, it should just be as simple as changing this to import the pillar version, and you may have to add pillar to Imports. https://github.com/sparklyr/sparklyr/blob/eb3e795447887908d9e795512ad08eeeb32eede5/R/imports.R#L5

[edgararuiz]

Hi, this means adding pillar as a dependency to sparklyr. Is type_sum() widely used? I'm considering just dropping the implementation for a Spark object.

[DavisVaughan]

Are you worried about adding pillar as an explicit dependency because you already have >20 imports and dont want to make CRAN upset? Otherwise you already implicitly require pillar through dplyr, so adding it as a dependency doesn't change anything.

An alternative is to add a vctrs::vec_ptype_abbr() method instead, as the default method of pillar::type_sum() will just forward to that. You already import vctrs so that seems like it would get around adding another import.

> pillar:::type_sum.default
function (x) 
{
    pillar_attr <- attr(x, "pillar", exact = TRUE)
    label <- pillar_attr$label
    if (!is.null(label)) {
        return(I(label))
    }
    if (is.object(x) || vec_is(x)) {
        return(vec_ptype_abbr(x))
    }
    switch(typeof(x), builtin = , special = , closure = "fn", 
        environment = "env", symbol = if (is_missing(x)) {
            "missing"
        } else {
            "sym"
        }, typeof(x))
}

[edgararuiz]

Ok, using vctrs may be the way to go. And yes, the main reason is the sheer number of direct dependencies sparklyr has, which stands today at 29.