add support for all hash field expiration commands

[sjpotter]

Description

adds the has field expiration commands - for testing purposes, need a docker container that has it in it.

---

Checklist

• Does npm test pass with this change (including linting)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

[leibale]

Overall looking good, but:

1. I've made some changes, please review them..
2. Seems like HGETF and HSETF are missing

[sjpotter]

change look fine

[leibale]

Shoule we create an "enum" for the reply just like in HPEXIRE?

[sjpotter]

created an enum

[sjpotter]

Overall looking good, but:

1. I've made some changes, please review them..

2. Seems like `HGETF` and `HSETF` are missing

wondering why you didn't do an enum like response for HEXPIRETIME?

[sjpotter]

Overall looking good, but:

1. I've made some changes, please review them..

2. Seems like `HGETF` and `HSETF` are missing

wondering why you didn't do an enum like response for HEXPIRETIME?

I see why, as it returns a negative number on "error" (enum) and any positive number on "success", and can't capture that conception in typescript.

[sjpotter]

otherwise changes looks fine, and I messed up initial tests, thanks for fixing.

[leibale]

We can make an enum for HEXPIRETIME and use a type like

type x = 1 | 2 | number;

I think that some users will find the enum useful..

[sjpotter]

We can make an enum for HEXPIRETIME and use a type like

type x = 1 | 2 | number;

I think that some users will find the enum useful..

so I tried something like that, but it seemed like it ended up being shown as just number (as number is a superset of 1/2)

[leibale]

It's possible, but a bit more complicated than that
https://www.totaltypescript.com/tips/create-autocomplete-helper-which-allows-for-arbitrary-values

and even if we don't use that in the return type, I think that some users will still find the enum useful (something like reply === HASH_EXPIRATION.FIELD_DOES_NOT_EXISTS is more readable than reply === -2)

[sjpotter]

I agree, but I can't seem to get omit to work with NumberReply as NumerReply expects a number subtype, but Omit doesn't seem to return an number that can be used by it, and when I created a type manually without NumberReply, it didn't seem to make a difference in practice, was still just number.

but yes, I created the enum to use, just unsure how to expose it to the user.

export const HASH_FIELD_EXPIRETIME = {
/** The field does not exist /
FIELD_NOT_EXISTS: -2,
/* The field has no expiration time */
NO_EXPIRATION_TIME: -1,
} as const;