What do you use now that password grant type got deprecated, in a scenario where you have only 1 client and it's yours (so you can trust the client)?
I know that authorization code is considered to be the best practice now, because you don't reveal user's credentials in headers of a request to a server. But I find it really inconvenient from user standpoint to redirect them to authorization server (which is also yours) and to redirect them back to the client (which is also yours) again.
I just want to have a simple form-based login/signup option in a typical case of a full-stack application where front is a next.js application and back is a restful spring boot application, but i can't find out what is the best decision and what should I actually use. I also thought of implementing my own system (where user would give his credentials to a server, server would send these credentials to a server, server would give client id and secret, client would get from server access token and refresh token using his id and secret, implementing all that with JWTs), but it really seems like implementation of the same OAuth2 password grant type and i really don't want to create a hammer instead of a table
Code flow is the recommended solution. You should use it if you want to stick to OAuth. I don't agree that redirects are inconvenient for the user. Most of the time, the user won't even notice that she is redirected to another page.
I just want to have a simple form-based login/signup option in a typical case of a full-stack application
You just answered your question yourself :) If you don't have a need for OAuth, then don't use it. Just stick to plain-old, cookie-based sessions and let your users log in with a username and password.
One thing a separate, OAuth-based authorization server gives you is the ability to easily expand the ways in which your users log in. For example, if, at some point, you want to add "Log in with Google" or 2-factor authentication, then you will have to implement support for it both in your backend server and on the front end. With a separate authorization server, you just do it in the server itself. If you use a product (as opposed to building your own authorization server), then very often you will be able to add new authentication methods just by configuring some options. Still, if you feel you won't have a need for those, then stick to a simple HTML form implemented in your backend.