net/mlx5: DR, Change SWS usage to debug fs seq_file interface

In current SWS debug dump mechanism we implement the seq_file interface,
but we only implement the 'show' callback to dump the whole steering DB
with a single call to this callback.

However, for large data size the seq_printf function will fail to
allocate a buffer with the adequate capacity to hold such data.

This patch solves this problem by utilizing the seq_file interface
mechanism in the following way:
- when the user triggers a dump procedure, we will allocate a list of
buffers that hold the whole data dump (in the start callback)
- using the start, next, show and stop callbacks of the seq_file
API we iterate through the list and dump the whole data

Signed-off-by: Hamdan Igbaria <hamdani@nvidia.com>
Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>

net/mlx5: DR, Add support for dumping steering info

Extend mlx5 debugfs support to present Software Steering resources:
dr_domain including it's tables, matchers and rules.
The interface is read-only. While dump is being presented, new steering
rules cannot be inserted/deleted.

The steering information is dumped in the CSV form with the following
format:

<object_type>,<object_ID>, <object_info>,...,<object_info>

This data can be read at the following path:

/sys/kernel/debug/mlx5/<BDF>/steering/fdb/<domain_handle>

Example:

# cat /sys/kernel/debug/mlx5/0000:82:00.0/steering/fdb/dmn_000018644
3100,0x55caa4621c50,0xee802,4,65533
3101,0x55caa4621c50,0xe0100008

Changes in V2:
- Reduce temp hex buffer size and avoid unnecessary memset
- Use bin2hex() instead of DIY loop
- Don't check debugfs functions return values

Signed-off-by: Muhammad Sammar <muhammads@nvidia.com>
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>